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

[Phil R. <p.d...@gm...>]

Okay, well if you need any help or testing let me know.

Something that I haven't seen up to now (but maybe I never looked hard enough) is a spec sheet for how to write a driver, I.e. What events should a buffer deal with and in what way. Given the effort I've just been through with rewriting wxWidgets driver and what you are going through with the windows driver, perhaps we should write it, and then we can refer to it and if we wish to tidy the core-driver interface in the future it will be a useful reference.

Phil

-----Original Message-----
From: "Jim Dishaw" <ji...@di...>
Sent: ‎13/‎06/‎2015 19:11
To: "Phil Rosenberg" <p.d...@gm...>
Cc: "Alan W. Irwin" <ir...@be...>; "PLplot development list" <Plp...@li...>
Subject: Re: [Plplot-devel] Bug fix to plbuf.c



On Jun 13, 2015, at 1:13 PM, Phil Rosenberg <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. 


Phil


From: Jim Dishaw
Sent: ‎13/‎06/‎2015 17:55
To: Alan W. Irwin
Cc: PLplot development list
Subject: Re: [Plplot-devel] Bug fix to plbuf.c




On Jun 13, 2015, at 12:03 PM, Jim Dishaw <ji...@di...> wrote:




On Jun 11, 2015, at 12:29 AM, Jim Dishaw <ji...@di...> wrote:



On Jun 10, 2015, at 11:30 PM, Alan W. Irwin <ir...@be...> 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...@gm...>
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.