Re: [Plplot-devel] Bug fix to plbuf.c

[Jim D. <ji...@di...>]

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 <ji...@di...> wrote:
> 
>> 
>> On Jun 14, 2015, at 1:40 PM, Jim Dishaw <ji...@di...> wrote:
>> 
>> 
>>> On Jun 14, 2015, at 5:19 AM, Alan W. Irwin <ir...@be...> wrote:
>>> 
>>> On 2015-06-13 22:29-0400 Jim Dishaw wrote:
>>> 
>>>> 
>>>>> On Jun 13, 2015, at 2:11 PM, Jim Dishaw <ji...@di...> wrote:
>>>>> 
>>>>> 
>>>>> On Jun 13, 2015, at 1:13 PM, Phil Rosenberg <p.d...@gm... <mailto:p.d...@gm...>> 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
> Plp...@li... <mailto:Plp...@li...>
> https://lists.sourceforge.net/lists/listinfo/plplot-devel <https://lists.sourceforge.net/lists/listinfo/plplot-devel>