On Jun 14, 2015, at 1:40 PM, Jim Dishaw <j...@dishaw.org> wrote:
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).
Attached is a patch series that implements the second solution. I tested the changes to xwin driver; however, I was not able to test tkwin, qt, or cairo. I will provide an update to wingcc separately. I didn’t touch the wxwidgets driver.I didn’t have to touch the drivers that do not need the wait function pointer (e.g. postscript). The way the driver dispatch table is initialized, I was able to set all the function pointers to NULL in the plcore.c file. The drivers set each member individually, thus the wait function pointer is left NULL.The xwin driver occasionally misses some resizes, but I think that is some quirky behavior that existed prior to 5.10. If someone could test the tkwin, qt, and cairo (specifically xcairo) that would be greatly appreciated.<0001-Fix-to-the-multiple-keypress-bug-on-page-advance.patch>------------------------------------------------------------------------------_______________________________________________Plplot-devel mailing listPlplot-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/plplot-devel
|
0002-Updated-the-wingcc-driver-to-reflect-the-changes-for.patch