> On Jun 13, 2015, at 3:25 PM, Phil Rosenberg <p.d.rosenb...@gmail.com> wrote: > > 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. >
Absolutely. Writing a driver should not be this hard. I think getting things documented might clear some of the problems between what we think is happening and what is really happening. > Phil > From: Jim Dishaw > Sent: 13/06/2015 19:11 > To: Phil Rosenberg > Cc: Alan W. Irwin; PLplot development list > Subject: Re: [Plplot-devel] Bug fix to plbuf.c > > >> On Jun 13, 2015, at 1:13 PM, Phil Rosenberg <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. > >> 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 <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
