Re: [Plplot-devel] Slave displays

[Alan W. I. <ir...@be...>]

On 2017-10-03 00:50+0100 Phil Rosenberg wrote:

> I think I see how this works now.
> Basically the example plots to both streams then execution halts while
> it waits for the page to advance on the "master" plot. But this isn't
> specifically due to coms between any of the streams, it is simply
> because without setting plspause(0) execution hangs until the page
> advances. Once enter is hit, the next page for both streams gets
> rendered.

I realize now that explanation is not complete, and I believe the
following explanation clarifies matters.  Example 14 calls plspause(0)
only for the second (slave) stream.  Because of that false argument
that sets plsc->nopause to true (the same setting as you get with just
one stream if you use the -np ("no pause") command-line option).  So
this means there should be NO pauses at page end waiting for the event
of the user to hit the enter key FOR the second slave stream, but
there will be such pauses for the master stream. The key additioal
point is the slave stream must halt in any case (at least when core is
also doing the rendering) whenever plsstrm is called to switch from
slave stream to he master stream.  So the behaviour for tk, xcairo,
and qtwidget follows automatically from this with the master stream
the only stream in charge of waiting for the enter key from the user
at page end for the master stream.  So there must be some
long-standing bugs (likely some event variable that should be stored
in the pls->dev struct associated with the device but because it is
not it is causing pause cross-talk between the master and slave
streams) for the xwin and old wxwidgets devices (and possibly wingcc
and wingdi as well).

I will look into that side issue soon.  But please read on for my
advice to get the new wxwidgets device driver to act the same way as
the currently correct behaviour for the tk, xcairo, and qtwidget
devices.

> With wxWidgets however, when we reach the end of a page execution
> doesn't stop.

True for plsc->nopause true, but if plsc->nopause is false, the
wxplViewer rendering does pause while waiting for the event of the
user hitting the return key to complete the page and start the next
one.  However, it is true that at the same time, I don't think
the core stops, and I believe that is the key to this bug fix.

> The plplot core code continues to execute and send the
> commands to the wxPLViewer ready for rendering. This means the
> execution just runs all the way through and the slave plot basically
> disappears as it gets plotted.
>
> I'm not sure this behaviour is documented specifically anywhere. We
> can force execution to pause while we wait for a page advance to
> happen I guess. It's just a question of whether we want that or
> whether we would prefer to just plough through all the commands and
> have them sat ready to execute.

If plsc->nopause is false (the usual case), interactive devices which
are not the "new" wxwidgets deal with events in such a way that by
definition (since there is no separate viewer) the core AND further
rendering pauses at the end of each page to wait for the event of the
user hitting the enter key.  So I strongly believe (now) that "new"
wxwidgets should act the same
way for the core, i.e., when wxPLViewer is pausing the rendering at
the end of each page to wait for the event of the user hitting the
enter key, the core should be waiting as well.

In other words, what I think is happening for example 14 is the master
stream core continues and that mistake allows the slave core just to
continue as well (since the switch from slave stream to master stream
just keeps on trucking with master stream core passing control back
soon after to the slave stream core even though the wxPLViewer
corresponding to the master stream (but not master stream core) is
paused at page end waiting for the event of the user hitting the enter
key.)

So I predict this change will make new wxwidgets act correctly like
tk, xcairo, and qtwidget for example 14.  I assume to make the core
stream stop when the wxPLViewer corresponding to that stream is at
page end and waiting for the event of the user hitting the return key
means using transmitBytes in viewer and receiveBytes in core
appropriately to send a command to the core to stop.  But it would
take me a long time to implement that (because of low C++ skills and
not much understanding of the wxwidgets code other than the
transmitBytes and receiveBytes logic) and I also plan to work on the
above side issue.  So I hope you have followed my arguments above and
will follow up by implementing this fix instead of me (which has the
added benefit that I will continue to not mess with the wxwidgets code
while you are working on this so you don't have to deal with
conflicts in that code).

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
__________________________