> On Jun 14, 2015, at 5:19 AM, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: > > On 2015-06-13 22:29-0400 Jim Dishaw wrote: > >> >>> On Jun 13, 2015, at 2:11 PM, Jim Dishaw <j...@dishaw.org> wrote: >>> >>> >>> On Jun 13, 2015, at 1:13 PM, Phil Rosenberg <p.d.rosenb...@gmail.com >>> <mailto:p.d.rosenb...@gmail.com>> wrote: >>> >>>> Hmmm >>>> Then hmmmm some more >>>> Followed by an ummm or two. >>>> >>>> As you say Jim, clearly things are more complicated than I realised. I'm >>>> not sure what the requirements really are here now. Now you have brought >>>> this up I can imagine the issues associated with entering the message loop >>>> after an eop. >>>> >>>> In terms of dealing with it, I'm not at my computer right now, but I think >>>> probably a bop_forced function which forces a bop irrespective of where we >>>> are in the page cycle would work. But I'm not sure if that might have some >>>> potential subtle effects elsewhere so it is a bit of a hack really. >>>> Perhaps instead it would be better to assess what is being done in a bop >>>> and ensure those actions end up in the buffer so a bop event is not >>>> required. >>>> >>> >>> I think that is a good approach for reasons beyond this issue, but a BOP >>> and EOP of some type is still required to support the drivers adequately >>> (e.g double buffering, printing from the windows API). >>> >>> The solution I'm going to test is one where the driver does not enter into >>> a wait for input state on a redraw event from the callback. >> >> I came up with two solutions, one of which I tested. >> >> Solution 1 (Tested) >> >> Remove the plP_eop() call in plRemakePlot(). Add an EOP to plbuf_eop() so >> now an EOP is written to the buffer. This will cause an EOP to be generated >> when the plot buffer is replayed. I like the symmetry of having an EOP in >> the buffer to match the BOP. >> >> Drivers will be responsible for determining if a “wait for user input” >> should be performed during an EOP. For the wingdi driver I track the state >> of a “page_state” that changes outside of the BOP/EOP calls. >> >> This solution feels a bit kludgy, but it works. >> >> Solution 2 >> >> Remove the plP_eop() call in plRemakePlot(). Add an EOP to plbuf_eop() so >> now an EOP is written to the buffer. This will cause an EOP to be generated >> when the plot buffer is replayed. >> >> Add a new driver function to the dispatch table (e.g. pl_wait) that calls >> the "wait for user input between pages" function. >> >> Remove from all drivers the “wait for input” from the EOP handler. >> >> The PLplot core library will call the wait for input between pages function >> (if not null). >> >> This solution strikes me as a more elegant solution because the logic for >> deciding about the wait for input is one spot. >> > >> Regardless of the solution, some changes to the drivers will be > required. Solution 2 will touch all the drivers (at a minimum to add > a NULL to the dispatch table). Solution 1 adds code to the drivers > while solution 2 removes some code from the drivers. > > Hi Jim: > > Thanks for your effort working through possible solutions to the > problem. > > @Phil and Andrew: > > Assuming you guys agree with Jim's analysis, do you prefer solution 1 > or 2? Elegant and "removes some code from the drivers" (i.e., > solution 2) seems like the better choice to me from an overview > perspective, but I would be happy to go along with whatever you all > decide since I do not have the driver expertise you guys have. > > Assuming whatever solution is decided upon here can be implemented > in a reasonably timely way, then I think we should be able to fit > it into the forthcoming bug-fix release since this is obviously a > bug fix, albeit a rather intrusive one. > > With regard to timing for that release there is still quite a bit I > plan to do to work through the bugs in the build system revealed by > previous tests on Linux and Arjen's current tests on the Cygwin > platform. And the new tarball report that is automatically collected > by scripts/comprehensive_test.sh should make reporting of tests and > figuring out build-system issues from those reports _much_ easier. > Which likely means this release will be tested on a lot more platforms > than the last one and a significant amount of time will be required to > deal with any build system bugs that are turned up by such tests. So > my current guestimate is the forthcoming release is likely more than a > month away (although hopefully not longer than two months away). >
The drivers that look at the npause of the PLStream structure are: drivers/cairo.c drivers/deprecated_wxwidgets.cpp drivers/linuxvga.c drivers/mem.c drivers/ntk.c drivers/pbm.c drivers/qt.cpp drivers/tek.c drivers/tk.c drivers/tkwin.c drivers/wingcc.c drivers/xwin.c Of those, the ones that use plRemakePlot() or the plot buffer are: drivers/tkwin.c drivers/wingcc.c drivers/xwin.c The new wxWidgets drivers Thus, implementing the second solution is fairly trivial for the non-plot buffer drivers (just need to split the EOP handler) Looking at the relevant files: The easy to split: cairo, linuxvga, qt, tk, twin, wingcc, xwin The “needs some thought”: ntk - driver pauses when the stream is destroyed (in the plD_tidy_ntk function rather than the EOP handler). tek - will need to move the CLEAR_VIEW in addition to splitting The false positives (they don’t actually pause, they set nopause to true): men, pbm The aqt driver is a mystery. It does not use the plot buffer nor does it look at the nopause member; however, it is an interactive driver. It should work with just a NULL in the wait handler because the EOP will be called only once. The dg300 is another example. ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
