> On Jan 12, 2017, at 3:49 PM, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: > >> On 2017-01-12 16:17-0000 Phil Rosenberg wrote: >> >> I think I've found the issue with clearing the page when using plreplot. >> Basically the issue is that the driver bop function is not being >> called, because at the point of replaying the buffer, the stream is >> already at the beginning of page. This means that the driver does not >> clear the page. >> >> There is a line in plFlushBuffer() which calls plP_eop() to avoid >> exactly this behaviour, however it is commented out. Using git blame I >> found the commit that commented the line out >> >> commit 5867959e87e64e08ed2ed57bc66a3cfa6e22450f >> Author: Jim Dishaw <j...@dishaw.org> >> Date: Mon Jun 15 12:10:04 2015 -0400 >> Fix to the multiple keypress bug on page advance >> - The "wait for user input" is not part of an EOP. >> -- A new function plP_wait() was created >> -- plP_wait() calls were added next to plP_eop() calls to generate >> a wait (if specified by nopause) after an EOP event >> - The plot buffer was modified to insert an EOP into the buffer >> -- No wait is inserted into the plot buffer because the plot buffer >> only regenerates plots >> - A new entry was added to the PLDispatchTable for the wait function >> -- The table initialization sets all function pointers to NULL via >> a memset >> -- If a driver does not specify a wait function, either it is not >> needed (e.g. the ps driver) or it is part of the EOP handler >> (legacy behavior) >> - The following drivers were modified to support the new >> implementation: cairo, qt, tkwin, and xwin. The wingcc update will be >> in a seperate fix. >> >> It's not entirely clear from the message, however it looks to me like >> this line was commented out to avoid odd behaviour when nopause was >> specified, but then Jim has fixed that issue in a different way and >> then perhaps forgotten to uncomment this line??? >> >> Jim, I know it's a long time ago when we were fixing the buffer, I >> don't suppose you have any memories of this? I have some vague ones >> but nothing concrete. >> >> Basically I'd like to put that line back for the upcoming release >> because I have code that is using plreplot that is currently broken >> because of this issue. I don't know what anyone thinks of that or what >> anyone thinks is an appropriate set of tests to do to ensure there >> isn't any odd side effects. > > To Phil and Jim: > > It would be great if Jim responded, but in addition this change was > thoroughly discussed at the time. To refresh your memories of that discussion > both of you should look at the June 2015 plplot-devel mailing list threads > entitled "The multiple keypress problem when using interactive > drivers" and (especially) "Bug fix to plbuf.c". > > I have just re-read those threads myself, and although I don't follow > all the technical issues it looks like Phil agreed at that time this > was a complex issue that Jim was facing. Ultimately with Phil's and > my encouragement Jim pushed his solution 2 (which he classified as the > more elegant one). > > That solution did require further device driver work for some of the > the interactive devices. Jim supplied those changes for wingcc, > cairo, qt, xwin, and tkwin, but the implication was Phil would have to > appropriately modify the wxwidgets driver (or wxPLViewer?) himself. > > @Phil: Is the wxwidgets issue you have recently discovered simply because you > never followed up with that required change? >
This is one of those whack-a-mole bugs and the correct fixed required some changes in the driver, as Alan pointed out. At the time I didn't make changes to the wxwidgets driver because it was being reworked at the time. The change for the driver entails implementing a wait for user input function, that is called by the plP_wait() function. > 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
