Hi Alan I literally just logged onto my email to say stop whatever you are doing on this the locate mode is broken!!! :-D
I think there may be a couple of different issues here. One is that the viewer is checking for more data being sent and the core code is waiting for the location information so we have a form of deadlock. The receiveBytes functions needs a timeout otherwise it will hang the viewer if there is a problem at the other end. Also with the 3sem method it probably makes no sense to keep checking for data once we have received a locate request. This is set by the m_locateMode variable. I also noticed that you have #ifdefed out the keypress code. Please don't remove this as it will need reinstating with the new method. Phil On 2 October 2017 at 19:29, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: > On 2017-10-02 08:02+0100 p.d.rosenb...@gmail.com wrote: > >> Hi Alan > > >> I haven't really en through that code, but yes I have been using t > > and yes I'm happy for that cleanup to occur. The joy of git is that > the code history is still here if needed. > >> So yes, feel free to clean up as you wish. > > > Well, I did one last check, and it turns out I got ahead of myself in > making this request, but I do appreciate the keeness you share with me > to get this code cleaned up as soon as warranted. But that time has > not (quite) arrived yet. > > The issue I spotted that currently (for the current HEAD of master) > has critically different results for -DPL_WXWIDGETS_IPC3=ON versus OFF > is -locate mode for example 1. > > If you run > > examples/c/x01c -dev wxwidgets -locate > > on Linux you get a blank screen with both the above configurations > which is a bug for both configurations. But now that I have looked > further, if you click blindly on the location of one of the 4 > subpages, you get some cursor position information printed to stdout > for the -DPL_WXWIDGETS_IPC3=OFF case and eventually the screen is > actually displayed for that case. In contrast for > -DPL_WXWIDGETS_IPC3=ON there is no response to mouse clicks for a > cursor position I know is in the right place, and therefore the > code is apparently in an infinite loop which never displays > anything other than a blank screen. > > Could you take a look at the above screen display issue, and also at > why there is no response to mouse clicks in locate mode for just the > -DPL_WXWIDGETS_IPC3=ON case? > > To familiarize yourself with how locate mode should work for this > example, you should try other interactive devices as well. For example, > > examples/c/x01c -dev wingcc -locate > > and/or > > examples/c/x01c -dev wingdi -locate > > should give good locate mode results (which is that if the mouse [or > some keyboard key if the driver supports keyboard clicking] is > clicked when the cursor corresponds to one of the 4 viewports, the > cursor position and other information is dumped to stdout; and if the > mouse [or keyboard key] is clicked when the cursor corresponds to a location > outside one > of the 4 viewports, locate mode terminates, and then hitting the enter > key will terminate the example.) I just checked, and the > old wxwidgets device you can still get access to using > -DOLD_WXWIDGETS=ON still builds and > > examples/c/x01c -dev wxwidgets -locate > > gives the good locate mode results (both with mouse clicks and > keyboard key clicks) described above. > > [out of order]: >> >> One question i did have though – I remember my code being set up > > like a ring buffer, and you saying yours wasn't. But I presume it can > still cope with large transfers bigger than the shared memory block? > > Yes, transferring large blocks of bytes in either direction is what > two of the three semaphores control. This works without any timed > waits at all. (The other semaphore controls use of the entire > transfer method similar to your mutex). My speed tests showed that > method of transferring bytes stopped being significantly dependent on > shared memory buffer size as soon as that shared memory size (+ a > small overhead) was 1KB or greater. So to be absolutely safe > concerning efficiency I set it to 10KB (+ a small overhead). See the > note concerning PL_SHARED_ARRAY_SIZE in drivers/wxwidgets_comms.h. > That value is significantly smaller than the ring buffer size which is > set to 1024K (in drivers/wxwidgets_dev.cpp) for the case when > PL_WXWIDGETS_IPC3 is not #defined. > > > 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
