Re: [Plplot-devel] Slave displays
Yes I agree
On 3 October 2017 at 10:24, Alan W. Irwin 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).
Re: [Plplot-devel] Slave displays
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
implementati
Re: [Plplot-devel] Slave displays
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. With wxWidgets however, when we reach the end of a page execution doesn't stop. 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. Phil On 2 October 2017 at 23:30, Alan W. Irwin wrote: > On 2017-10-02 16:10+0100 Phil Rosenberg wrote: > >> Hi Alan >> I've been going through the various wxWidgets bugs on the bug tracker. >> The ones that remain are the rather more technical ones or the ones >> that I'm not sure what the correct behaviour should be. >> >> In particular the slave display thing is a bit of a puzzle to me. >> Searching for slave in the documentation doesn't yield any results and >> all I see in example 14 is two streams used, the second of which has >> had plspause( 0 ) called on it. Is that what sets up a slave display. >> If so it really needs some documentation indicating what triggers a >> slave display and how they should work. > > > To Phil, Maurice, Hazen, Hez, and Andrew: > > @Phil: > > I don't understand the details about exactly what plspause does, but > it does depend on an implementation in each individual interactive > device driver so you are going to have to read the plspause parts of > the source code for one or more other devices to make further progress > on this bug. > > However, to help you to choose what to look at I did some further > experiments. > > For the new wxwidgets device I still get the same incorrect behaviour > as reported in the bug report. That is, the slave plot GUI first > displays a blank plot rather than the actual slave plot and then > immediately dies. Meanwhile, the primary plot GUI displays > fine, and moves to the second page and exits if the user hit the enter > key twice. This result is the same both for -DPL_WXWIDGETS_IPC3=ON > and OFF. For the old wxwidgets device (-DOLD_WXWIDGETS=ON) the > behaviour is exactly the same as -dev xwin. That is both primary and > secondary master and slave GUI's display their respective plots, and > if you hit the enter key on either of those two GUI's, BOTH plots > advance a page (which is actually also incorrect behaviour, but at > least you don't have the "blank page and die" behaviour for > the slave that you get with new wxwidgets). > > So the xwin and old wxwidgets models are not quite the best ones to > follow here for master/slave behaviour. And I suspect that is also > true of -dev wingcc and -dev wingdi because I think they modelled > their plspause on -dev xwin. But you should double-check that. > > Instead, you should be attempting to implement the same behaviour as > demonstrated by any of the tk, qtwidget and xcairo > devices; > both master and slave GUI plots are displayed, but the enter key is a no-op > for the slave > GUI, and only for the master GUI does the enter key advance the pages > for both GUI's and eventually exit the example. > > In sum, I suggest you look carefully at the old wxwidgets device code > to solve the "blank plot and die" issue with the slave plot for new > wxwidgets. Once that bug is solved, then I would follow exactly > however either of our qtwidget or xcairo devices implement plspause to > obtain the correct master/slave behaviour. I am not suggesting you > attempt to understand plspause parts of the -dev tk code because that > device driver logic is tough to follow in my opinion. But it is > interesting that although the -dev tk logic uses important parts of > the -dev xwin code it gets the master/slave behaviour correct while > pure -dev xwin code does not achieve that. > > @Maurice: > > I believe plspause was implemented by you long ago and presumably tested > by you on the interactive devices available to you (i.e, -dev xwin > and -dev tk since our cairo and qt device drivers hadn't been > implemented back then). I would appreciate you commenting further > and especially about the differences between master/slave behaviour > between -dev xwin and the closely related -dev tk. > > @Hazen, Hez, and Andrew: > It is very likely that one of you made the master/slave relationship work > so well for xcairo and/or qtwidget. If so I would appreciate you > commenting further. > > Alan > __ > Alan W. Irwin > > Astr
Re: [Plplot-devel] Slave displays
On 2017-10-02 16:10+0100 Phil Rosenberg wrote: Hi Alan I've been going through the various wxWidgets bugs on the bug tracker. The ones that remain are the rather more technical ones or the ones that I'm not sure what the correct behaviour should be. In particular the slave display thing is a bit of a puzzle to me. Searching for slave in the documentation doesn't yield any results and all I see in example 14 is two streams used, the second of which has had plspause( 0 ) called on it. Is that what sets up a slave display. If so it really needs some documentation indicating what triggers a slave display and how they should work. To Phil, Maurice, Hazen, Hez, and Andrew: @Phil: I don't understand the details about exactly what plspause does, but it does depend on an implementation in each individual interactive device driver so you are going to have to read the plspause parts of the source code for one or more other devices to make further progress on this bug. However, to help you to choose what to look at I did some further experiments. For the new wxwidgets device I still get the same incorrect behaviour as reported in the bug report. That is, the slave plot GUI first displays a blank plot rather than the actual slave plot and then immediately dies. Meanwhile, the primary plot GUI displays fine, and moves to the second page and exits if the user hit the enter key twice. This result is the same both for -DPL_WXWIDGETS_IPC3=ON and OFF. For the old wxwidgets device (-DOLD_WXWIDGETS=ON) the behaviour is exactly the same as -dev xwin. That is both primary and secondary master and slave GUI's display their respective plots, and if you hit the enter key on either of those two GUI's, BOTH plots advance a page (which is actually also incorrect behaviour, but at least you don't have the "blank page and die" behaviour for the slave that you get with new wxwidgets). So the xwin and old wxwidgets models are not quite the best ones to follow here for master/slave behaviour. And I suspect that is also true of -dev wingcc and -dev wingdi because I think they modelled their plspause on -dev xwin. But you should double-check that. Instead, you should be attempting to implement the same behaviour as demonstrated by any of the tk, qtwidget and xcairo devices; both master and slave GUI plots are displayed, but the enter key is a no-op for the slave GUI, and only for the master GUI does the enter key advance the pages for both GUI's and eventually exit the example. In sum, I suggest you look carefully at the old wxwidgets device code to solve the "blank plot and die" issue with the slave plot for new wxwidgets. Once that bug is solved, then I would follow exactly however either of our qtwidget or xcairo devices implement plspause to obtain the correct master/slave behaviour. I am not suggesting you attempt to understand plspause parts of the -dev tk code because that device driver logic is tough to follow in my opinion. But it is interesting that although the -dev tk logic uses important parts of the -dev xwin code it gets the master/slave behaviour correct while pure -dev xwin code does not achieve that. @Maurice: I believe plspause was implemented by you long ago and presumably tested by you on the interactive devices available to you (i.e, -dev xwin and -dev tk since our cairo and qt device drivers hadn't been implemented back then). I would appreciate you commenting further and especially about the differences between master/slave behaviour between -dev xwin and the closely related -dev tk. @Hazen, Hez, and Andrew: It is very likely that one of you made the master/slave relationship work so well for xcairo and/or qtwidget. If so I would appreciate you commenting further. 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
[Plplot-devel] Slave displays
Hi Alan I've been going through the various wxWidgets bugs on the bug tracker. The ones that remain are the rather more technical ones or the ones that I'm not sure what the correct behaviour should be. In particular the slave display thing is a bit of a puzzle to me. Searching for slave in the documentation doesn't yield any results and all I see in example 14 is two streams used, the second of which has had plspause( 0 ) called on it. Is that what sets up a slave display. If so it really needs some documentation indicating what triggers a slave display and how they should work. Phil -- 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
