> 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. > >> Phil >> From: Jim Dishaw <mailto:j...@dishaw.org> >> Sent: 13/06/2015 17:55 >> To: Alan W. Irwin <mailto:ir...@beluga.phys.uvic.ca> >> Cc: PLplot development list <mailto:Plplot-devel@lists.sourceforge.net> >> Subject: Re: [Plplot-devel] Bug fix to plbuf.c >> >> >>> On Jun 13, 2015, at 12:03 PM, Jim Dishaw <j...@dishaw.org >>> <mailto:j...@dishaw.org>> wrote: >>> >>> >>>> On Jun 11, 2015, at 12:29 AM, Jim Dishaw <j...@dishaw.org >>>> <mailto:j...@dishaw.org>> wrote: >>>> >>>>> >>>>> On Jun 10, 2015, at 11:30 PM, Alan W. Irwin <ir...@beluga.phys.uvic.ca >>>>> <mailto:ir...@beluga.phys.uvic.ca>> wrote: >>> <snip> >>>>> Just to confirm that I just now played a lot with resizing of >>>>> >>>>> examples/c/x01c -dev xwin >>>>> >>>>> for 5.10.0, 5.11.0, and git master tip (including your recent commit), >>>>> and I found no specific string issues for any of those cases. So it >>>>> appears hard (at least with this example) to demonstrate a rendering >>>>> bug due to this issue that you just fixed, but your fix seems logical >>>>> to me (now) and certainly does not introduce any bad string rendering >>>>> that I can spot. >>>>> >>>>> However, when doing those checks I did notice other resizing issues >>>>> that do need to be addressed. >>>>> >>>>> 1. As a resize is occurring (typically by dragging one edge or one >>>>> corner of the GUI to make the whole thing smaller or larger) sometimes >>>>> the displayed GUI is a scaled plot and sometimes it is black (which is >>>>> OK). But on some occasions when I stop resizing (by releasing the >>>>> mouse button) the result remains black for 5.11.0 and the master tip >>>>> version (which is not OK). But 5.10.0 is fine in this regard. So this >>>>> issue is a regression introduced into PLplot between 5.10.0 and 5.11.0 >>>>> and probably due to the flurry of changes you and Phil made in plbuf >>>>> before we released 5.11.0. >>>> >>>>> >>>>> Please verify the good result for 5.10.0 and bad result for 5.11.0, >>>>> git bisect to figure out what commit has caused the issue, and then >>>>> make the appropriate plbuf fix to get rid of this regression. >>>>> >>>> >>>> I think this problem is the plP_eop() that was inserted in the >>>> plRemakePlot() to make sure the BOP would perform as expected. For the >>>> GUI drivers this will trigger another wait for input, which ends up >>>> blocking redraw messages. I will verify by using git bisect. >>> >>> I ran git bisect and the regression was introduced in the commit >>> 1e402417c1f3e87c391fe428f936153c2a10e8cc >>> >>> Author: Phil Rosenberg <p.d.rosenb...@gmail.com >>> <mailto:p.d.rosenb...@gmail.com>> >>> Date: Fri Feb 27 17:12:03 2015 +0000 >>> >>> Fixed bug in rdbuf_di. >>> >>> Save cursubpage on replot >>> call plP_eop() on replot which ensures that the first plP_bop() call >>> actually does something. >>> >>> If I comment out the plP_eop() that was added to plbuf.c in that commit, >>> the xwin driver does not exhibit the problematic behavior. I will >>> investigate further on working on a patch. I know why it is causing a >>> problem, but it isn’t obvious to me how it gets to that point. >>> >> >> I found the cause of the problem and the plP_eop() is not acting in a way >> that neither Phil nor I expected. Phil put the plP_eop() in to make sure >> that the BOP will do something and I thought that will always to lead to the >> keypress bug. In reality the plP_eop() does something only half the time. >> >> 1) Plot starts >> 2) At BOP, the page_status is set to AT_BOP >> 3) While drawing, the page_status is set to DRAWING >> 4) At EOP, the page_status is set to AT_EOP (the EOP is not put into the >> buffer) >> 5) The driver enters into a loop waiting for messages >> 6) Driver receives a resize message >> 7) plRemakePlot is called >> 8) plRemakPlot() calls plP_eop() >> 9) plP_eop() does nothing because it exits immediately because the >> page_status is AT_EOP >> 10) The plot buffer is replayed >> 11) At BOP, the page_status is set to AT_BOP >> 12) While drawing, the page_status is set to DRAWING >> 13) No EOP is generated because it is not in the buffer, thus the >> page_status is unchanged >> 14) Control returns the message loop >> 15) Another resize message is received >> 16) plRemakePlot is called >> 17) plRemakePlot() calls plP_eop() >> 18) plP_eop() does not exit immediately this time because page_state is >> DRAWING >> 19) plP_eop() calls the driver EOP handler >> 20) The driver enters into a new loop waiting for messages >> 21) User has to do an action (e.g. keypress) to exit the new message loop. >> This blocks many messages because the windowing system still considers the >> window to be processing a resize. >> 22) Once the new message loop exits, the driver EOP handler exits. >> 23) Goto step 10. >> >> Just putting the EOP into the plot buffer won’t fix the problem because a >> new message loop will be called, which will block messages. >> >> I agree with Phil’s point about the need to call plP_eop(). Some drivers >> may need the EOP handler to work correctly (e.g. double buffering). The way >> the code is structured, the plP_eop() is only doing something 50% of the >> time. >> >> I’m not sure the best way to fix this. I think the interactive GUI drivers >> might need to be modified to check if they are already waiting. One thing >> that makes this tricky is the strip chart function. As it is currently >> written, it does not generate an EOP until the end. Thus, it cannot be >> resized while plotting. Plus, when resized, the entire strip chart is >> replayed (though I see Phil has made some commits so wxWidgets might be >> smarter). >> >> I’m going to experiment on some different approaches and see what works best. >> > ------------------------------------------------------------------------------ > _______________________________________________ > Plplot-devel mailing list > Plplot-devel@lists.sourceforge.net <mailto:Plplot-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/plplot-devel > <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
