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.
Phil
-----Original Message-----
From: "Jim Dishaw" <j...@dishaw.org>
Sent: 13/06/2015 17:55
To: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
Cc: "PLplot development list" <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> wrote:
On Jun 11, 2015, at 12:29 AM, Jim Dishaw <j...@dishaw.org> wrote:
On Jun 10, 2015, at 11:30 PM, Alan W. Irwin <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>
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
