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 <ir...@beluga.phys.uvic.ca> 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 > > 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
