Hi Phil: On 2017-01-13 08:48-0000 p.d.rosenb...@gmail.com wrote:
> Thanks Alan, I'll review those emails. Good. Here is my understanding from reviewing those e-mails and looking at code. I think the qt device driver is a good model for what has to be done. So if you look at Jim's changes for it, via git diff 5867959e^..5867959e drivers/qt.cpp you will see no changes for any of the noninteractive devices, but for the qtwidget device what happened previously in the eop code is now split into an "eop" routine that only exercises "non-wait" code and a "wait" routine that exercises all former eop code that waits. Currently there is no such wait routine in drivers/wx*.cpp, but I think you might need it since what is currently called wxPLDevice::EndPage has logic that depends on pls->nopause. So it appears that what you need to do is to follow what was done for qt and split all such wait code that is currently exercised by the eop routine into its own wait routine. If you agree this is the right way to go, then please go ahead with the implementation but also exercise extreme caution about pushing it, i.e., wait until you, Pedro, and I have thoroughly tested it on all platforms by building _both_ the test_c_wxwidgets (which exercises a subset of the examples with -dev wxwidgets and the -np option) and test_wxPLplotDemo targets on Linux and also by running one example with -dev wxwidgets on that platform without the -np option, and by doing the equivalent tests (running at least one example with -dev wxwidgets with and without the -np option and running wxPLplotDemo) for the MSVC case. Given such testing, I would be happy to see you push this in time for the 5.12.0 release because there are no impacts of such wxwidgets driver changes on any other part of PLplot. However, the reason why I suggest extreme caution about pushing is that Jim's equivalent change for cairo was a complete success for both -dev xcairo and ext-cairo-test, but it appeared to have a side effect of exposing a bug in extXdrawable_demo which we could not fix in a timely manner for the release of 5.11.1. Therefore, Jim and I made the joint decision then to revert his change to cairo.c (see commit d64d9c684) until someone could figure out that extXdrawable_demo issue. As of this date nobody has found such a solution so Jim's fix for xcairo still remains reverted. But if your equivalent change for wxwidgets works, then post-release I plan to reinstate Jim's fix for xcairo and simply drop extXdrawable_demo until someone can figure out the issue with it. In any case, in anticipation that you will be looking very carefully at the eop versus wait distinction in plbuf, I suggest you document that distinction clearly (in drivers/README.drivers or some other file that document refers to) so no other interactive driver writers run afoul of this issue. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
