Yes I agree
On 3 October 2017 at 10:24, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote:
> 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
> __________________________
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
