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). 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 __________________________ ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
