Thanks Alan, I'll review those emails.
I will check if the issue is related, but it shouldn't be a keypress issue as
I'm not using it in that way.
PS, I wasn't suggesting the commit was wrong. Just that I couldn't remember why
it was as it was.
Perhaps also, I could be using plreplot wrong. I was using plclear wrong, as I
was calling it before the first pladv() call so it was clearing no page. I'm
not sure whether there should be a call to pladv before plreplot. I'll
experiment.
I'm just thinking now whether the wxWidgets driver should clear the whole page
to the background colour at bop. I guess it should.
Phil
Sent from my Windows 10 phone
From: Alan W. Irwin
Sent: 12 January 2017 20:50
To: Phil Rosenberg; Jim Dishaw; plplot-devel@lists.sourceforge.net
Subject: Re: [Plplot-devel] plreplot and clearing the page (jim please read
ifyou'e around)
On 2017-01-12 16:17- Phil Rosenberg wrote:
> I think I've found the issue with clearing the page when using plreplot.
> Basically the issue is that the driver bop function is not being
> called, because at the point of replaying the buffer, the stream is
> already at the beginning of page. This means that the driver does not
> clear the page.
>
> There is a line in plFlushBuffer() which calls plP_eop() to avoid
> exactly this behaviour, however it is commented out. Using git blame I
> found the commit that commented the line out
>
> commit 5867959e87e64e08ed2ed57bc66a3cfa6e22450f
> Author: Jim Dishaw
> Date: Mon Jun 15 12:10:04 2015 -0400
>Fix to the multiple keypress bug on page advance
>- The "wait for user input" is not part of an EOP.
> -- A new function plP_wait() was created
> -- plP_wait() calls were added next to plP_eop() calls to generate
> a wait (if specified by nopause) after an EOP event
>- The plot buffer was modified to insert an EOP into the buffer
> -- No wait is inserted into the plot buffer because the plot buffer
> only regenerates plots
>- A new entry was added to the PLDispatchTable for the wait function
> -- The table initialization sets all function pointers to NULL via
> a memset
> -- If a driver does not specify a wait function, either it is not
> needed (e.g. the ps driver) or it is part of the EOP handler
> (legacy behavior)
>- The following drivers were modified to support the new
> implementation: cairo, qt, tkwin, and xwin. The wingcc update will be
> in a seperate fix.
>
> It's not entirely clear from the message, however it looks to me like
> this line was commented out to avoid odd behaviour when nopause was
> specified, but then Jim has fixed that issue in a different way and
> then perhaps forgotten to uncomment this line???
>
> Jim, I know it's a long time ago when we were fixing the buffer, I
> don't suppose you have any memories of this? I have some vague ones
> but nothing concrete.
>
> Basically I'd like to put that line back for the upcoming release
> because I have code that is using plreplot that is currently broken
> because of this issue. I don't know what anyone thinks of that or what
> anyone thinks is an appropriate set of tests to do to ensure there
> isn't any odd side effects.
To Phil and Jim:
It would be great if Jim responded, but in addition this change was
thoroughly discussed at the time. To refresh your memories of that discussion
both of you should look at the June 2015 plplot-devel mailing list threads
entitled "The multiple keypress problem when using interactive
drivers" and (especially) "Bug fix to plbuf.c".
I have just re-read those threads myself, and although I don't follow
all the technical issues it looks like Phil agreed at that time this
was a complex issue that Jim was facing. Ultimately with Phil's and
my encouragement Jim pushed his solution 2 (which he classified as the
more elegant one).
That solution did require further device driver work for some of the
the interactive devices. Jim supplied those changes for wingcc,
cairo, qt, xwin, and tkwin, but the implication was Phil would have to
appropriately modify the wxwidgets driver (or wxPLViewer?) himself.
@Phil: Is the wxwidgets issue you have recently discovered simply because you
never followed up with that required change?
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linu
