> On Jun 16, 2015, at 5:27 PM, Phil Rosenberg <p.d.rosenb...@gmail.com> wrote: > > Okay, so it sounds like there is basically no change for drivers that are > waiting to be updated. > If you need me to have a look at the patches I will try to do so tomorrow.
The wxWidgets driver will need to be updated to work correctly because it uses the plot buffer. Without an updated, it will need an extra keypress after a resize event. Extra eyes on the patches is appreciated. Thanks. > > Phil > From: Jim Dishaw <mailto:j...@dishaw.org> > Sent: 16/06/2015 16:11 > To: Phil Rosenberg <mailto:p.d.rosenb...@gmail.com> > Cc: Alan W. Irwin <mailto:ir...@beluga.phys.uvic.ca>; PLplot development list > <mailto:Plplot-devel@lists.sourceforge.net>; Andrew Ross > <mailto:andrewr...@users.sourceforge.net> > Subject: Re: [Plplot-devel] Bug fix to plbuf.c > > > > On Jun 16, 2015, at 4:58 AM, Phil Rosenberg <p.d.rosenb...@gmail.com> wrote: > > > > So how should we go about applying all this? Will we break some > > drivers when it is applied? If so do we need to have all drivers > > prepared so that we can apply all the fixes together? > > > > All function pointer are set to NULL during the dispatch table > initialization, thus the wait pointer remains NULL if a device does not set > it. The plP_wait() function checks nopause and for a non-NULL wait function > pointer before calling the wait function pointer. Thus no action is taken if > a driver does not support the wait function. > > For non-interactive drivers, no further action is required because they don’t > wait for input. > > For interactive drivers, the key factor is if the driver uses plRemakePlot(). > If it does, it will need to provide a wait function otherwise multiple > keypresses will be required after a resize. If it does not use > plRemakePlot(), the change is not critical because having a wait for input in > the driver’s EOP handler will not break anything. The driver should be > updated to keep the internal API consistent. For example, the tek driver is > in an unsupported state and there is no need to update it. The Qt driver, on > the other hand, should be updated to stay consistent with the internal API > even though it does not use plRemakePlot(). If during testing we discover Qt > behaves badly with this change, we can leave the changes out until a later > release. > > > Phil > > > > On 16 June 2015 at 02:55, Jim Dishaw <j...@dishaw.org> wrote: > >> And here is the wingcc patch series. I tested with cygwin and msvc and did > >> not have the problem with multiple keypresses. The wingcc driver does seem > >> to have a problem when the window is made small. It cuts off part of the > >> plot. > >> > >> > >> > >> > >> On Jun 15, 2015, at 12:24 PM, Jim Dishaw <j...@dishaw.org> wrote: > >> > >> > >> 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 list > >> Plplot-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/plplot-devel > >> > >> > >> > >> ------------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> Plplot-devel mailing list > >> Plplot-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/plplot-devel > >> >
------------------------------------------------------------------------------
_______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
