> On Jun 13, 2015, at 12:03 PM, Jim Dishaw <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 https://lists.sourceforge.net/lists/listinfo/plplot-devel
