Re: [Plplot-devel] plreplot and clearing the page (jim please read if you'e around)

[Jim Dishaw]

> On Jan 12, 2017, at 3:49 PM, Alan W. Irwin  wrote:
> 
>> 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?
> 

This is one of those whack-a-mole bugs and the correct fixed required some 
changes in the driver, as Alan pointed out.  At the time I didn't make changes 
to the wxwidgets driver because it was being reworked at the time.

The change for the driver entails implementing a wait for user input function, 
that is called by the plP_wait() function. 

> 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 Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __
> 
> Linux-powered Science
> __


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Plplot-devel mailing list

Re: [Plplot-devel] plreplot and clearing the page (jim please read if you'e around)

[Alan W. Irwin]

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 Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] plreplot and clearing the page (jim please read if you'e around)

[Phil Rosenberg]

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.

Phil

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel