plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] Further to your recent comment for wxwidgets gradient bug 173

[Phil R. <p.d...@gm...>]

👍

On 5 October 2017 at 00:38, Alan W. Irwin <ir...@be...> wrote:
> On 2017-10-05 00:28+0100 Phil Rosenberg wrote:
>
>>>
>>> Once confirmed, then the obvious next question is why are we using a
>>> subset of the wxGraphicsContext class indirectly via the wxGCDC class
>>> rather than using the wxGraphicsContext class directly (which would
>>> provide important native gradient capability for the new wxwidgets
>>> device driver)?
>>>
>>
>> Ah, there are some good reasons. Because by using a wxDC we get access
>> to the following derived classes which render to the following formats
>> wxGCDC (GraphicsContext, which renders to memory or to a printer)
>> wxMemoryDC (memory which can then be saved as a bitmap (bmp, jpg,
>> tiff, png) or blitted to a window - on windows lower quality than GCDC
>> but hardware accelerated)
>> wxMetafileDC (Windows metafile)
>> wxMirrorDC (reflects allong x=y line and passes to another wxDC)
>> wxPostscriptDC (postscript files)
>> wxPrinterDC (Printing)
>> wxScreenDC (Rendering directly onto the screen rather than a window)
>> wxSVGFileDC (SVG file output)
>> wxPaintDC (Rendering to a window)
>> Plus quite possibly other people's custom wxDCs - for example I once
>> started writing a Direct2D wxDC, but never finished it.
>>
>> Thats kind of how OO programming works. A base class defines a common
>> structure and the derived classes expand that base structure. But if I
>> do not care what kind of DC I am working with then I just request a
>> wxDC* and use just that common base structure can deal with all the
>> derived classes equally. Then when I call wxDC->DrawRectangle() I
>> neither know nor care whether that writes text to a ps file, sends a
>> command to a printer or sets pixels in memory.
>>
>> As it happens when I slimmed things down to just accepting wxDCs in
>> the wxWidgets driver, the wxGCDC had just become available which was
>> brilliant, but either wxGraphicsContexts were not able to render to a
>> printer or I wasn't aware of that option. So those things swung me in
>> favour of wxDC over wxGraphicsContext.
>>
>> So having access to all the derived classes is one reason. The other
>> is that if we swapped to using a wxGraphicsContext we would silently
>> break everyone's code because of our casting of a void* to a wxDC,
>> that would instead get cast to a wxGraphicsContext, this would just
>> generate segfaults in all our users' code. The final reason is time. I
>> don't have time to rewrite the driver again using wxGraphicsContext
>> and I deliberately went for only wxDC at the last rewrite because
>> wxGCDC had become available and it halved the maintenance time
>> compared to having two separate backends.
>>
>> Lastly I will say that it is possible to check if we are dealing with
>> a wxGCDC and get access to the underlying wxGraphicsContext. I have
>> done this for text rendering because wxDC does not support arbitrary
>> affine transformations as needed for the 3D style text. But I really
>> don't want to make a habit of it. I'd much rather try the rotated
>> clipped rectangle and keep total consistency.
>>
>> Anyway that was a much longer explanation than intended ;-)
>
>
> That's fine.  I liked all those details in your good answer to my
> question.  :-)
>
>
> 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
> __________________________

Re: [Plplot-devel] Further to your recent comment for wxwidgets gradient bug 173

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

On 2017-10-05 00:28+0100 Phil Rosenberg wrote:

>>
>> Once confirmed, then the obvious next question is why are we using a
>> subset of the wxGraphicsContext class indirectly via the wxGCDC class
>> rather than using the wxGraphicsContext class directly (which would
>> provide important native gradient capability for the new wxwidgets
>> device driver)?
>>
>
> Ah, there are some good reasons. Because by using a wxDC we get access
> to the following derived classes which render to the following formats
> wxGCDC (GraphicsContext, which renders to memory or to a printer)
> wxMemoryDC (memory which can then be saved as a bitmap (bmp, jpg,
> tiff, png) or blitted to a window - on windows lower quality than GCDC
> but hardware accelerated)
> wxMetafileDC (Windows metafile)
> wxMirrorDC (reflects allong x=y line and passes to another wxDC)
> wxPostscriptDC (postscript files)
> wxPrinterDC (Printing)
> wxScreenDC (Rendering directly onto the screen rather than a window)
> wxSVGFileDC (SVG file output)
> wxPaintDC (Rendering to a window)
> Plus quite possibly other people's custom wxDCs - for example I once
> started writing a Direct2D wxDC, but never finished it.
>
> Thats kind of how OO programming works. A base class defines a common
> structure and the derived classes expand that base structure. But if I
> do not care what kind of DC I am working with then I just request a
> wxDC* and use just that common base structure can deal with all the
> derived classes equally. Then when I call wxDC->DrawRectangle() I
> neither know nor care whether that writes text to a ps file, sends a
> command to a printer or sets pixels in memory.
>
> As it happens when I slimmed things down to just accepting wxDCs in
> the wxWidgets driver, the wxGCDC had just become available which was
> brilliant, but either wxGraphicsContexts were not able to render to a
> printer or I wasn't aware of that option. So those things swung me in
> favour of wxDC over wxGraphicsContext.
>
> So having access to all the derived classes is one reason. The other
> is that if we swapped to using a wxGraphicsContext we would silently
> break everyone's code because of our casting of a void* to a wxDC,
> that would instead get cast to a wxGraphicsContext, this would just
> generate segfaults in all our users' code. The final reason is time. I
> don't have time to rewrite the driver again using wxGraphicsContext
> and I deliberately went for only wxDC at the last rewrite because
> wxGCDC had become available and it halved the maintenance time
> compared to having two separate backends.
>
> Lastly I will say that it is possible to check if we are dealing with
> a wxGCDC and get access to the underlying wxGraphicsContext. I have
> done this for text rendering because wxDC does not support arbitrary
> affine transformations as needed for the 3D style text. But I really
> don't want to make a habit of it. I'd much rather try the rotated
> clipped rectangle and keep total consistency.
>
> Anyway that was a much longer explanation than intended ;-)

That's fine.  I liked all those details in your good answer to my
question.  :-)

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
__________________________

Re: [Plplot-devel] Further to your recent comment for wxwidgets gradient bug 173

[Phil R. <p.d...@gm...>]

>
> Once confirmed, then the obvious next question is why are we using a
> subset of the wxGraphicsContext class indirectly via the wxGCDC class
> rather than using the wxGraphicsContext class directly (which would
> provide important native gradient capability for the new wxwidgets
> device driver)?
>

Ah, there are some good reasons. Because by using a wxDC we get access
to the following derived classes which render to the following formats
wxGCDC (GraphicsContext, which renders to memory or to a printer)
wxMemoryDC (memory which can then be saved as a bitmap (bmp, jpg,
tiff, png) or blitted to a window - on windows lower quality than GCDC
but hardware accelerated)
wxMetafileDC (Windows metafile)
wxMirrorDC (reflects allong x=y line and passes to another wxDC)
wxPostscriptDC (postscript files)
wxPrinterDC (Printing)
wxScreenDC (Rendering directly onto the screen rather than a window)
wxSVGFileDC (SVG file output)
wxPaintDC (Rendering to a window)
Plus quite possibly other people's custom wxDCs - for example I once
started writing a Direct2D wxDC, but never finished it.

Thats kind of how OO programming works. A base class defines a common
structure and the derived classes expand that base structure. But if I
do not care what kind of DC I am working with then I just request a
wxDC* and use just that common base structure can deal with all the
derived classes equally. Then when I call wxDC->DrawRectangle() I
neither know nor care whether that writes text to a ps file, sends a
command to a printer or sets pixels in memory.

As it happens when I slimmed things down to just accepting wxDCs in
the wxWidgets driver, the wxGCDC had just become available which was
brilliant, but either wxGraphicsContexts were not able to render to a
printer or I wasn't aware of that option. So those things swung me in
favour of wxDC over wxGraphicsContext.

So having access to all the derived classes is one reason. The other
is that if we swapped to using a wxGraphicsContext we would silently
break everyone's code because of our casting of a void* to a wxDC,
that would instead get cast to a wxGraphicsContext, this would just
generate segfaults in all our users' code. The final reason is time. I
don't have time to rewrite the driver again using wxGraphicsContext
and I deliberately went for only wxDC at the last rewrite because
wxGCDC had become available and it halved the maintenance time
compared to having two separate backends.

Lastly I will say that it is possible to check if we are dealing with
a wxGCDC and get access to the underlying wxGraphicsContext. I have
done this for text rendering because wxDC does not support arbitrary
affine transformations as needed for the 3D style text. But I really
don't want to make a habit of it. I'd much rather try the rotated
clipped rectangle and keep total consistency.

Anyway that was a much longer explanation than intended ;-)

[Plplot-devel] wingcc and wingdi build bugs

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

To Phil, Jim, and Arjen:

On 2017-10-04 12:11+0100 Phil Rosenberg wrote:

> For some reason I cannot build wingcc or wingdi, they do not come up
> as enabled on my system when I run cmake. I have never looked into why
> as I don't use them.

But all members of the PLplot development team should be concerned if
wingcc (a workhorse interactive device that has been around a long
time and which presumably builds on most Windows platforms) does not
build on your particular Windows platform.  Because other users also
have that same platform, and they may need access to wingcc (and
wingdi).  So please follow up with a complete bug report here
(preferably) or on the bug tracker including all relevant information
about your Windows platform and the exact build error.  And similarly
for the wingdi case (although that has not been around as long as
wingcc it is based on it so it may have a common build problem on your
particular Windows platform).  Arjen or Jim (both with a lot
of Windows experience) might be able to quickly resolve the issue
you are encountering.

You might also want to look at
https://sourceforge.net/p/plplot/support-requests/44/
(which is in the support-request category, but it is really
a bug report).  That user was having trouble building wingdi
on "Cygwin 64 (CYGWIN_NT-10.0) on Winows 10 (64-bit)".  But for
that same platform he built wingcc with no issues.

@Jim:

You obviously had a lot of discussion with this user concerning his
wingdi build bug including sending him patches to try, but it seemed
to trail off at the end with nothing resolved with regard to the
wingdi build bug on his platform.  What needs to be done to get this
issue resolved?

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
__________________________

Re: [Plplot-devel] Further to your recent comment for wxwidgets gradient bug 173

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

On 2017-10-04 11:53+0100 Phil Rosenberg wrote:

> On 3 October 2017 at 18:00, Alan W. Irwin <ir...@be...> wrote:
>> On 2017-10-03 11:24+0100 Phil Rosenberg wrote:
>>
>>> Hi Alan
>>> It may be possible to do as you said with a clip region and an affine
>>> transform. I did consider this but I am not sure if the gradient gets
>>> transformed or just the polygon shape. I would have to check.
>>>
>>> Regarding inheritance, you have the correct syntax. wxDC and
>>> wxGraphicsContext are pretty close to top level classes so only
>>> inherit from wxObject, which many wxWidgets classes inherit from and I
>>> think it basically allows conversion between classes and strings which
>>> specify the class name. If you look in the docs,
>>> e.g.http://docs.wxwidgets.org/3.1/classwx_d_c.html, there is usually
>>> an inheritance diagram. You have access to all the functions towards
>>> the base of the tree, but the magic of C++ is that the behaviour of
>>> some of the functions can be redefined towards the branches of a tree
>>> by using the virtual specifier. So for example wxDC has a virtual
>>> function DrawLines. So if I have a pointer to a wxDC I can always call
>>> myDcPointer->DrawLines(/*params*/). But then if that pointer actually
>>> points to an inherited class then the inherited class's version of
>>> that function is called, so a wxPostscriptDC would write the vector to
>>> the file, a wxMemoryDC would work out which pixels need shading and
>>> shade them, etc.
>>
>>
>> Hi Phil:
>>
>> I don't claim to understand everything you have said above in your
>> second paragraph, but if the upshot is there are C++ ways to give us
>> access to all wxWidget library methods regardless of the class they
>> are in, then I suggest the most promising way forward (since the
>> documentation does not mention any limitations on this brush) is
>> likely to be to use wxGraphicsContext::CreateLinearGradientBrush
>> rather than wxDC::GradientFillLinear (which does have many documented
>> limitations).
>
> No, sadly it does not. I can only access functions that are in wxDC.
> wxGraphicsContext is neither a parent nor a child class to wxDC, it is
> totally unrelated.
> The wxGCDC class is a child of wxDC. It takes wxDC commands and then
> calls equivalent wxGraphicsContext commands. This is how we make use
> of the wxGraphicsContexts rendering.

Hi Phil:

Please follow up with the
wxWidgets gurus you know to confirm whether
wxGraphicsContext::CreateLinearGradientBrush would provide linear
gradients in arbitrary directions to fill an arbitrary polygon. The
SVG file format as well as pango/cairo and Qt libraries support such
gradients so our standalone svg device and all our "cairo" and "qt"
devices support native gradients. So I am pretty sure that
wxGraphicsContext::CreateLinearGradientBrush does support such
gradients (because the documentation mentioning no limitations and I
assume the wxWidgets developers would like to keep up with their
competition). But it is essential to get that confirmed.

Once confirmed, then the obvious next question is why are we using a
subset of the wxGraphicsContext class indirectly via the wxGCDC class
rather than using the wxGraphicsContext class directly (which would
provide important native gradient capability for the new wxwidgets
device driver)?

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
__________________________

Re: [Plplot-devel] Some remaining wxwidgets inefficiency concerns for examples 17 and 08

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

On 2017-10-04 12:11+0100 Phil Rosenberg wrote:

Note, I am including everything you wrote here (as opposed to dropping
parts of it) because the list has
not seen what you wrote because of the plplot-devel address that I flubbed.

I also respond in a few places below.

> On 4 October 2017 at 05:54, Alan W. Irwin <ir...@be...> wrote:
>> On 2017-10-03 23:44+0100 Phil Rosenberg wrote:
>>
>>> On Windows the fill test took 5 seconds using the old comms method and
>>> 12 with the new. That's with optimisations turned on and I just timed
>>> it with my phone stopwatch from the point where I hit enter after
>>> choosing the driver.
>>>
>>> Interestingly I ran the viewer in a profiler to see why the
>>> differences. Running the 3sem version first, it spent almost all its
>>> time in a GDI rendering function, so no reason to think that the
>>> different comms would make any difference. However, when I profiled
>>> the old comms method, the profiler showed that the viewer spent all
>>> it's time in a different GDI rendering function - this time called
>>> NtGDIPolyPolyDraw. I saw something in wxWidgets the other day. This
>>> was a function also called something like PolyPolygonFill and it said
>>> that using this function plotting many polygons at once was faster
>>> than plotting them all individually. So I am going to guess that GDI
>>> maybe has some runtime optimisation or something and it was able to
>>> better optimise the old comms than the new 3sem one. Maybe the
>>> polygons arrive more rapidly?????
>>
>>
>> That's an interesting comparison, and it sure is a surprise that the
>> IPC method affects how the GDI rendering is optimized.  My bet is it
>> has nothing to do with specifically how the data are transmitted and
>> assembled, and instead that difference in GDI rendering optimization
>> is due to some "minor" difference in the code paths between IPC3 and
>> non-IPC3 case on the viewer side.  In other words, instead of looking
>> at transmitBytes and receiveBytes details, I think you should be
>> looking for IPC3 and non-IPC3 differences in utils/wxplframe.cpp
>> concerning how wxPlFrame::ReadTransmission() is called and also the
>> large number of IPC3 versus non-IPC3 code-path differences within that
>> routine.
>>
>> Since the above is an interesting comparison I have decided to add
>> it to my results as well.
>>
>> Just to be clear about nomenclature,
>>
>> IPC3 wxwidgets is what I previously called default wxwidgets and which you
>> have called new comms.  You get that by default or by
>> specifying -DOLD_WXWIDGETS=OFF -DPL_WXWIDGETS_IPC3=ON
>>
>> The non-IPC3 wxwidgets result I have added is what you have called
>> old comms.  You get that by specifying -DOLD_WXWIDGETS=OFF
>> -DPL_WXWIDGETS_IPC3=OFF
>>
>> The old wxwidgets result corresponds to Werner's wxwidgets-related
>> software as updated by you until you decided to do completely rewrite
>> that software.  You get that by specifing -DOLD_WXWIDGETS=ON
>>
>> So here is my old timing result table with non-IPC3 wxwidgets timings added
>> where those added timings are defined in exactly the same way and with
>> the same compiler options as the others.
>>
>> device              plline test    plfill test
>> IPC3 wxwidgets      26  seconds    32  seconds
>> non-IPC3 wxwidgets  27  seconds    32  seconds
>> old wxwidgets       18  seconds    30  seconds
>> xcairo              1.4 seconds    2.2 seconds
>> qtwidget            1.5 seconds    1.6 seconds
>> xwin                9.5 seconds    3.4 seconds
>>
>> So on Linux there is no significant measured time difference between
>> what you call new comms (IPC3) and old coms (non-IPC3) contrary to
>> your results on MSVC Windows.
>>
>> So just one timing comparison like you did on a given platform is
>> tricky to generalize, and to get a better idea of what is going on for
>> a given platform it is a good idea to get as many comparisons as
>> possible. Therefore, could you please fill out a similar table to the
>> above with the first 3 devices the same and the last two for wingcc
>> and wingdi?  For example, if the three wxwidgets variants are roughly
>> the same speed as wingcc and wingdi, then it is likely there is
>> some remaining efficiency issue that just occurs for the Linux case.
>> But if on your platform all wxwidgets variants are roughly an order of
>> magnitude slower
>> than wingcc and wingdi, then we likely have a cross-platform efficiency
>> issue
>> with -dev wxwidgets.
>
> For some reason I cannot build wingcc or wingdi, they do not come up
> as enabled on my system when I run cmake. I have never looked into why
> as I don't use them.

I will say more on this topic separately, but for now then
please fill in the first three rows since you do have access to
all those variations of wxwidgets.

>
>>
>>> I wonder why so slow on Linux?
>>
>>
>> I have been wondering about that issue forever.... :-)
>>
>> More seriously though, it is certainly possible there is a unique
>> inefficiency issue on Linux that makes all IPC3 versus non-IPC3
>> comparisons look identical in (very slow) speed.  Also, as you know
>> such cross-platform time comparisons are notoriously unreliable since
>> we have different hardware, different underlying graphics systems
>> which wxwidgets necessarily wraps in extremely different ways,
>> different wxwidgets releases (probably), different compilers, and
>> different levels of optimizations of libraries and PLplot.  So I would
>> prefer to reserve judgement on MSVC Windows versus Linux comparisons
>> until you fill in the rest of the requested table, and probably only
>> pay attention to the relative results even then rather than the
>> absolute results.
>>
>> By the way, I should have mentioned the above table was created
>> with the current HEAD of master branch (commit 124a0c3) with
>> no local changes (other than the two different patches
>> to examples/c/x00c.c to produce the plline and plfill tests above).
>> So when you produce your table would you be sure to do the same?
>>
>>> Do you have a profiler you can use?
>>> Again if you uncomment #define WXPLVIEWER_DEBUG, then set the example
>>> running normally it will display the command line params that you can
>>> use to execute wxPLViewer in a profiler to see where it is spending
>>> its time. There really is no other good way to work out the timings
>>> other than by using a profiler as there are so many unexpected
>>> optimisations that can happen.
>>
>>
>> I have never done profiling, but I agree this is an excellent idea
>> both for core and viewer for the 6 simple examples (plline and
>> plfill for the three wxwidgets variants).
>>
>> I am quite familiar with valgrind so I am thinking of using callgrind
>> <https://www.cs.cmu.edu/afs/cs.cmu.edu/project/cmt-40/Nice/RuleRefinement/bin/valgrind-3.2.0/docs/html/cl-manual.html>
>> to do the profiling.
>>
>> What do you think of that callgrind description and have you heard any
>> caveats/kudos about it?
>>
>> One caveat with valgrind (and presumably callgrind) is identification
>> of source code lines depends on the -g option symbols being available
>> for the library. For wxwidgets, Debian apparently provides those
>> symbols in separate packaged form, e.g., package libwxbase3.0-0-dbg,
>> and my extrapolation from some web discussion is such
>> wxWidgets-related *-dbg packages will automatically allow me to
>> profile (with source-code line identifications) the official wxWidgets
>> Debian libraries.  But I will see.
>
> I think that is a feature of all profilers and debuggers. But I got
> the impression that most linux libraries were distributed with the
> debug information. Maybe I'm mistaken. I can't really comment on
> callgrind. I chose to use a tool called very sleepy. It was
> recommended as very easy to use. It is a graphical tool - I simply
> enter a command to run or select a currently running process and it
> repeatedly checks over and over which function the current execution
> path is in and which line of code it is executing until either the
> process ends or you tell it to stop. Then I can view a heirarchy of %
> time spent in each function or load a page of code and see time spent
> on each line.  I think some profilers work a bit like debuggers
> tracking function calls. I don't know which is better. I've only used
> very sleepy and found it perfect for my needs so never changed. Visual
> Studio now has a profiler built in, but I haven't played with it
> really other than that it shows diagnostics like CPU and memory usage
> when I run stuff from the IDE.
>
> Of course beware - your optimiser will agressively inline things, so I
> would often find that whole classes had 0 execution time because they
> had been totally optimised away. This is of course a good thing as it
> is the optimiser doing its job, but it just means a little care must
> be taken when interpretting profiler info.

OK.  Thanks for that profiling advice.

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
__________________________

Re: [Plplot-devel] Some remaining wxwidgets inefficiency concerns for examples 17 and 08

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

Phil, you should have seen the message below recently, but I am sending it again
because I flubbed the plplot-devel address for the first send.

On 2017-10-03 23:44+0100 Phil Rosenberg wrote:

> On Windows the fill test took 5 seconds using the old comms method and
> 12 with the new. That's with optimisations turned on and I just timed
> it with my phone stopwatch from the point where I hit enter after
> choosing the driver.
> 
> Interestingly I ran the viewer in a profiler to see why the
> differences. Running the 3sem version first, it spent almost all its
> time in a GDI rendering function, so no reason to think that the
> different comms would make any difference. However, when I profiled
> the old comms method, the profiler showed that the viewer spent all
> it's time in a different GDI rendering function - this time called
> NtGDIPolyPolyDraw. I saw something in wxWidgets the other day. This
> was a function also called something like PolyPolygonFill and it said
> that using this function plotting many polygons at once was faster
> than plotting them all individually. So I am going to guess that GDI
> maybe has some runtime optimisation or something and it was able to
> better optimise the old comms than the new 3sem one. Maybe the
> polygons arrive more rapidly?????

That's an interesting comparison, and it sure is a surprise that the
IPC method affects how the GDI rendering is optimized.  My bet is it
has nothing to do with specifically how the data are transmitted and
assembled, and instead that difference in GDI rendering optimization
is due to some "minor" difference in the code paths between IPC3 and
non-IPC3 case on the viewer side.  In other words, instead of looking
at transmitBytes and receiveBytes details, I think you should be
looking for IPC3 and non-IPC3 differences in utils/wxplframe.cpp
concerning how wxPlFrame::ReadTransmission() is called and also the
large number of IPC3 versus non-IPC3 code-path differences within that
routine.

Since the above is an interesting comparison I have decided to add
it to my results as well.

Just to be clear about nomenclature,

IPC3 wxwidgets is what I previously called default wxwidgets and which you have 
called new comms.  You get that by default or by
specifying -DOLD_WXWIDGETS=OFF -DPL_WXWIDGETS_IPC3=ON

The non-IPC3 wxwidgets result I have added is what you have called
old comms.  You get that by specifying -DOLD_WXWIDGETS=OFF
-DPL_WXWIDGETS_IPC3=OFF

The old wxwidgets result corresponds to Werner's wxwidgets-related
software as updated by you until you decided to do completely rewrite
that software.  You get that by specifing -DOLD_WXWIDGETS=ON

So here is my old timing result table with non-IPC3 wxwidgets timings added
where those added timings are defined in exactly the same way and with
the same compiler options as the others.

device              plline test    plfill test
IPC3 wxwidgets      26  seconds    32  seconds
non-IPC3 wxwidgets  27  seconds    32  seconds
old wxwidgets       18  seconds    30  seconds
xcairo              1.4 seconds    2.2 seconds
qtwidget            1.5 seconds    1.6 seconds
xwin                9.5 seconds    3.4 seconds

So on Linux there is no significant measured time difference between
what you call new comms (IPC3) and old coms (non-IPC3) contrary to
your results on MSVC Windows.

So just one timing comparison like you did on a given platform is
tricky to generalize, and to get a better idea of what is going on for
a given platform it is a good idea to get as many comparisons as
possible. Therefore, could you please fill out a similar table to the
above with the first 3 devices the same and the last two for wingcc
and wingdi?  For example, if the three wxwidgets variants are roughly
the same speed as wingcc and wingdi, then it is likely there is
some remaining efficiency issue that just occurs for the Linux case.
But if on your platform all wxwidgets variants are roughly an order of 
magnitude slower
than wingcc and wingdi, then we likely have a cross-platform efficiency issue
with -dev wxwidgets.

> I wonder why so slow on Linux?

I have been wondering about that issue forever.... :-)

More seriously though, it is certainly possible there is a unique
inefficiency issue on Linux that makes all IPC3 versus non-IPC3
comparisons look identical in (very slow) speed.  Also, as you know
such cross-platform time comparisons are notoriously unreliable since
we have different hardware, different underlying graphics systems
which wxwidgets necessarily wraps in extremely different ways,
different wxwidgets releases (probably), different compilers, and
different levels of optimizations of libraries and PLplot.  So I would
prefer to reserve judgement on MSVC Windows versus Linux comparisons
until you fill in the rest of the requested table, and probably only
pay attention to the relative results even then rather than the
absolute results.

By the way, I should have mentioned the above table was created
with the current HEAD of master branch (commit 124a0c3) with
no local changes (other than the two different patches
to examples/c/x00c.c to produce the plline and plfill tests above).
So when you produce your table would you be sure to do the same?

> Do you have a profiler you can use?
> Again if you uncomment #define WXPLVIEWER_DEBUG, then set the example
> running normally it will display the command line params that you can
> use to execute wxPLViewer in a profiler to see where it is spending
> its time. There really is no other good way to work out the timings
> other than by using a profiler as there are so many unexpected
> optimisations that can happen.

I have never done profiling, but I agree this is an excellent idea
both for core and viewer for the 6 simple examples (plline and
plfill for the three wxwidgets variants).

I am quite familiar with valgrind so I am thinking of using callgrind
<https://www.cs.cmu.edu/afs/cs.cmu.edu/project/cmt-40/Nice/RuleRefinement/bin/valgrind-3.2.0/docs/html/cl-manual.html>
to do the profiling.

What do you think of that callgrind description and have you heard any
caveats/kudos about it?

One caveat with valgrind (and presumably callgrind) is identification
of source code lines depends on the -g option symbols being available
for the library. For wxwidgets, Debian apparently provides those
symbols in separate packaged form, e.g., package libwxbase3.0-0-dbg,
and my extrapolation from some web discussion is such
wxWidgets-related *-dbg packages will automatically allow me to
profile (with source-code line identifications) the official wxWidgets
Debian libraries.  But I will see.

It is likely going to be a while before I can start profiling because
I really would like to solve the cross-stream contamination issue I
seem to have discovered via example 14 for at least the xwin and old
wxwidgets devices. But I do realize how important profiling is now we
have some simple examples of the wxwidgets efficiency problem (at
least on Linux) for the plline and plfill cases.  So I won't forget to
follow up on this planned profiling, and I also hope you do the same
if it turns out your table of timing results show order of magnitude
inefficiencies with the wxwidgets device when compared to wingcc and
wingdi timing results for your platform.

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
__________________________

Re: [Plplot-devel] Update of the Wiki: obsolete information?

[Phil R. <p.d...@gm...>]

Good shout for updating these.
I notice that the Visual Studio IDE page that I wrote is woefully out
of date. I should sort that.

Phil

On 3 October 2017 at 07:50, Arjen Markus <Arj...@de...> wrote:
> Hi Alan, others,
>
>
>
> I have updated the Wiki page on the status of PLplot for the Windows
> platforms. I noticed however that we list information about the Borland and
> Open Watcom compilers, as well as the CGM device. I have not seen any
> mention of the two compilers or of the CGM device for many years now. Is it
> really convenient to continue displaying that information?
>
>
>
> By the way, I have added the newer languages to the overview and some of the
> newer components as well. I would appreciate comments – especially as far as
> the restrictions are concerned. If someone can point me to the missing
> components for Ocaml for instance or to a D compiler for Windows platforms,
> that would be great.
>
>
>
> Regards,
>
>
>
> Arjen
>
>
>
> DISCLAIMER: This message is intended exclusively for the addressee(s) and
> may contain confidential and privileged information. If you are not the
> intended recipient please notify the sender immediately and destroy this
> message. Unauthorized use, disclosure or copying of this message is strictly
> prohibited. The foundation 'Stichting Deltares', which has its seat at
> Delft, The Netherlands, Commercial Registration Number 41146461, is not
> liable in any way whatsoever for consequences and/or damages resulting from
> the improper, incomplete and untimely dispatch, receipt and/or content of
> this e-mail.
>
> ------------------------------------------------------------------------------
> 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
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

[Plplot-devel] xor mode and the buffer

[Phil R. <p.d...@gm...>]

Currently and rendering performed in xor mode is not recorded to the
buffer. I can understand why this would be the case as xor mode is
often used for rendering temporary lines then erasing them. However,
because wxPLViewer relies on the buffer for all its rendering this
means that it cannot support xor rendering. Does anyone have any
thoughts on the possibility of putting xor mode drawing in the buffer?
Or maybe making it an option? There are alternatives, but all of them
are significantly more conplex then simply logging xor rendering in
the buffer. Perhaps this could be a device option?

Re: [Plplot-devel] Is it time to remove some IPC cruft from our wxwidgets-related code?

[Phil R. <p.d...@gm...>]

On 3 October 2017 at 22:01, Phil Rosenberg <p.d...@gm...> wrote:
>>> Hi Alan
>>> I have been trying to work through your semaphore code, but I'm afraid
>>> I just don't quite get it.
>>>
>>> At the heart of this bug is the fact that receiveBytes() should be
>>> able to accept a timeout for waiting for the semaphore to unlock and
>>> instead of being void it should return the number of bytes it actually
>>> read.
>>>
>>> When I tried to implement this I just kept getting deadlocks because
>>> I'm not really sure how it all works.
>>
>>
>> Hi Phil:
>>
>> Because you are having trouble understanding the transmitBytes and
>> receiveBytes design, I think the best thing to do is for me to look
>> closely at the deadlock scenario you have described previously to see
>> if the current design answers it.  And if it doesn't, I will modify
>> transmitBytes and receiveBytes appropriately.  But this all will take
>> some substantial time on my part because I have other PLplot issues
>> (such as the cross-talk between streams that some interactive devices
>> show for example 14) on my plate right now.
>>
>> Meanwhile, you did say you had some sort of fix for locate mode
>> which you (much earlier in the recent discussions between us) described as
>>
>>> I have made a quick couple of changes that makes locate work correctly
>>> again with wxWidgets by simply halting checking for new data while
>>> doing a locate, then starting again when locate is complete.
>
> Yes, plus a full fix for the old style comms. I have also realised
> that I am not correctly filling in the state variable for the locate
> info, so example 20 is still not quite working as it should. However I
> am having some trouble capturing the mouse button release. Once I have
> that worked out I will push the changes.
>
>>
>>
>> But you were reluctant to push those changes at that time, and I don't
>> think you have done so since.  If these changes do not involve the
>> introduction of timed waits or modifications to transmitBytes and
>> receiveBytes is there any reason to not push them? But if they do
>> involve such changes (e.g., to work around the deadlock you think is
>> there), then please don't push them and send me the patch instead to
>> help educate me about that issue.
>
> Yes it's a workaround rather than a proper fix. There really does need
> to be a timeout when the viewer checks for more data otherwise it
> causes all sorts of problems with possible deadlocks and also just
> unresponsive windows, i.e. resizes won't work and windows won't close
> while the viewer is waiting for the semaphore. You can see the
> deadlock by running example 20 with -nosombrero (you need this as
> there is another problem that will be fixed by the commit I mentioned
> above). You will find both sides of the communication hang. You can
> also uncomment the #define WXPLVIEWER_DEBUG line in wxWidgets_dev,
> then run x20c in a debugger - it will give you the command to run
> wxPLViewer in another debugger instance so you can see the point at
> which the hang occurs. Basically the core code is sat waiting for the
> locate data and the viewer has carried on repeatedly checking for new
> data so cannot actually collect the locate data.

I have just commited the workaround. But sadly it turned out not to be
very reliable. I'm not sure why. I am now sometimes able to get past
page 2 of example 20, but sometimes it hangs before I can leave and
sometimes it hangs later in the sequence. The non-IPC3 method is
currently working perfectly with locate.

Re: [Plplot-devel] Further to your recent comment for wxwidgets gradient bug 173

[Phil R. <p.d...@gm...>]

On 3 October 2017 at 18:00, Alan W. Irwin <ir...@be...> wrote:
> On 2017-10-03 11:24+0100 Phil Rosenberg wrote:
>
>> Hi Alan
>> It may be possible to do as you said with a clip region and an affine
>> transform. I did consider this but I am not sure if the gradient gets
>> transformed or just the polygon shape. I would have to check.
>>
>> Regarding inheritance, you have the correct syntax. wxDC and
>> wxGraphicsContext are pretty close to top level classes so only
>> inherit from wxObject, which many wxWidgets classes inherit from and I
>> think it basically allows conversion between classes and strings which
>> specify the class name. If you look in the docs,
>> e.g.http://docs.wxwidgets.org/3.1/classwx_d_c.html, there is usually
>> an inheritance diagram. You have access to all the functions towards
>> the base of the tree, but the magic of C++ is that the behaviour of
>> some of the functions can be redefined towards the branches of a tree
>> by using the virtual specifier. So for example wxDC has a virtual
>> function DrawLines. So if I have a pointer to a wxDC I can always call
>> myDcPointer->DrawLines(/*params*/). But then if that pointer actually
>> points to an inherited class then the inherited class's version of
>> that function is called, so a wxPostscriptDC would write the vector to
>> the file, a wxMemoryDC would work out which pixels need shading and
>> shade them, etc.
>
>
> Hi Phil:
>
> I don't claim to understand everything you have said above in your
> second paragraph, but if the upshot is there are C++ ways to give us
> access to all wxWidget library methods regardless of the class they
> are in, then I suggest the most promising way forward (since the
> documentation does not mention any limitations on this brush) is
> likely to be to use wxGraphicsContext::CreateLinearGradientBrush
> rather than wxDC::GradientFillLinear (which does have many documented
> limitations).

No, sadly it does not. I can only access functions that are in wxDC.
wxGraphicsContext is neither a parent nor a child class to wxDC, it is
totally unrelated.
The wxGCDC class is a child of wxDC. It takes wxDC commands and then
calls equivalent wxGraphicsContext commands. This is how we make use
of the wxGraphicsContexts rendering.

Re: [Plplot-devel] Some remaining wxwidgets inefficiency concerns for examples 17 and 08

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

On 2017-10-03 12:34+0100 Phil Rosenberg wrote:

> Can I also just check, in the end what was wrong with the previous
> comms that I put in place? Didn't we eventually find that the source
> of the delays was the random number generator for determining the name
> of the shared memory and nothing to do with the actual comms?

You posted the above question as an add-on to the locate thread, but I
am replying to this question in the thread devoted to inefficiencies
(see the different subject line) just to keep our discussions of
different topics disentangled from each other.

That fix you refer to above was a huge Linux success that removed
order-of-magnitude inefficiencies with wxwidgets for most of our
standard examples. But resolution of that one ineffienciy still left
some order-of-magnitude inefficiences for the wxwidgets device for
just a small subset of the examples such as example 17 and example 8.

Furthermore, the problem with those complex examples is we can only
make informed speculation about the cause of the wxwidgets
inefficiencies for them so I have decided to make much simpler test
examples (see below) which respectively call plline many times and
plfill many times to test the speculations that it is many separate
graphical line elements and many separate graphical fill elements that
are the source of the respective wxwidgets inefficiencies for examples
17 and 8.

Simple plline test.

This simple example is a variant of standard C example 00 (see
attached patch so you can check the efficiency of this simple test
yourself) that creates 50000 distinct medium-sized right triangles,
and for each of them calls plline.

Simple plfill test.

This simple example is a variant of standard C example 00 (see
attached patch so you can check the efficiency of this simple test
yourself) that creates 50000 distinct medium-sized right triangles,
and for each of them calls plfill.

Here are the timed results (from the launch of the core example to end
of rendering (by core example in most cases, but by wxPLViewer in the
wxwidgets case). Note the wxwidgets result is for default wxwidgets
(new version of that device and IPC3).  In all cases I did not use the
-np option.  Thus, to stop the rendering in a timely manner I had to
lean on the enter key with the cursor pointing at the GUI so the GUI
had focus and could interpret that key strike as end the GUI.

device              plline test    plfill test
default wxwidgets   26  seconds    32  seconds
old wxwidgets       18  seconds    30  seconds
xcairo              1.4 seconds    2.2 seconds
qtwidget            1.5 seconds    1.6 seconds
xwin                9.5 seconds    3.4 seconds

So from these timing results both plline and plfill are an
order-of-magnitude less efficient for -dev wxwidgets (both new and old
versions) than for the bulk (everything but the plline case for xwin)
of the other interactive devices on Linux.

Can we say the same thing for the Windows (MSVC) platform?  To
establish that important answer, please do the equivalent timing
results for these two simple examples on Windows where the table of
results you should collect similar to the above should be for the
default wxwidgets, old wxwidgets, wingcc, and wingdi devices.  Once
we have that answer we should be able to figure out further strategies
for finding the source of these large plline and plfill -dev wxwidgets
inefficiencies.

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
__________________________

Re: [Plplot-devel] Is it time to remove some IPC cruft from our wxwidgets-related code?

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

On 2017-10-03 12:34+0100 Phil Rosenberg wrote:

> Hi Alan
> I have been trying to work through your semaphore code, but I'm afraid
> I just don't quite get it.
>
> At the heart of this bug is the fact that receiveBytes() should be
> able to accept a timeout for waiting for the semaphore to unlock and
> instead of being void it should return the number of bytes it actually
> read.
>
> When I tried to implement this I just kept getting deadlocks because
> I'm not really sure how it all works.

Hi Phil:

Because you are having trouble understanding the transmitBytes and
receiveBytes design, I think the best thing to do is for me to look
closely at the deadlock scenario you have described previously to see
if the current design answers it.  And if it doesn't, I will modify
transmitBytes and receiveBytes appropriately.  But this all will take
some substantial time on my part because I have other PLplot issues
(such as the cross-talk between streams that some interactive devices
show for example 14) on my plate right now.

Meanwhile, you did say you had some sort of fix for locate mode
which you (much earlier in the recent discussions between us) described as

> I have made a quick couple of changes that makes locate work correctly
> again with wxWidgets by simply halting checking for new data while
> doing a locate, then starting again when locate is complete.

But you were reluctant to push those changes at that time, and I don't
think you have done so since.  If these changes do not involve the
introduction of timed waits or modifications to transmitBytes and
receiveBytes is there any reason to not push them? But if they do
involve such changes (e.g., to work around the deadlock you think is
there), then please don't push them and send me the patch instead to
help educate me about that issue.

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
__________________________

Re: [Plplot-devel] Further to your recent comment for wxwidgets gradient bug 173

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

On 2017-10-03 11:24+0100 Phil Rosenberg wrote:

> Hi Alan
> It may be possible to do as you said with a clip region and an affine
> transform. I did consider this but I am not sure if the gradient gets
> transformed or just the polygon shape. I would have to check.
>
> Regarding inheritance, you have the correct syntax. wxDC and
> wxGraphicsContext are pretty close to top level classes so only
> inherit from wxObject, which many wxWidgets classes inherit from and I
> think it basically allows conversion between classes and strings which
> specify the class name. If you look in the docs,
> e.g.http://docs.wxwidgets.org/3.1/classwx_d_c.html, there is usually
> an inheritance diagram. You have access to all the functions towards
> the base of the tree, but the magic of C++ is that the behaviour of
> some of the functions can be redefined towards the branches of a tree
> by using the virtual specifier. So for example wxDC has a virtual
> function DrawLines. So if I have a pointer to a wxDC I can always call
> myDcPointer->DrawLines(/*params*/). But then if that pointer actually
> points to an inherited class then the inherited class's version of
> that function is called, so a wxPostscriptDC would write the vector to
> the file, a wxMemoryDC would work out which pixels need shading and
> shade them, etc.

Hi Phil:

I don't claim to understand everything you have said above in your
second paragraph, but if the upshot is there are C++ ways to give us
access to all wxWidget library methods regardless of the class they
are in, then I suggest the most promising way forward (since the
documentation does not mention any limitations on this brush) is
likely to be to use wxGraphicsContext::CreateLinearGradientBrush
rather than wxDC::GradientFillLinear (which does have many documented
limitations).

(Note, this speculation jibes with the [now ancient] advice at
<http://wxwidgets.10942.n7.nabble.com/Gradient-Fill-for-Rounded-Rectangle-td28295.html>
that filling a non-rectangular area with a gradient can only be done
with wxGraphicsContext.)

To follow up my speculation above, would you be willing to check with
your wxWidgets contacts if
wxGraphicsContext::CreateLinearGradientBrush can be used in the way I
describe to paint a native gradient at any angle for any
non-rectangular area?

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
__________________________

Re: [Plplot-devel] Is it time to remove some IPC cruft from our wxwidgets-related code?

[Phil R. <p.d...@gm...>]

Hi Alan
I have been trying to work through your semaphore code, but I'm afraid
I just don't quite get it.

At the heart of this bug is the fact that receiveBytes() should be
able to accept a timeout for waiting for the semaphore to unlock and
instead of being void it should return the number of bytes it actually
read.

When I tried to implement this I just kept getting deadlocks because
I'm not really sure how it all works.

Can I also just check, in the end what was wrong with the previous
comms that I put in place? Didn't we eventually find that the source
of the delays was the random number generator for determining the name
of the shared memory and nothing to do with the actual comms?

On 3 October 2017 at 09:07, Phil Rosenberg <p.d...@gm...> wrote:
>>
>> It is good that you are doing some critical thinking about my bytes
>> transmission logic this way.  However, it appears you are referring to
>> the case where there are two separate but simultaneous uses of IPC
>> (one to send an array of data from core to viewer and one to send an
>> array of data from viewer to core).
>
> Hi Alan
> Actually I am talking about the opposite case. Both core and viewer
> make a receive request. In both cases the receiveBytes function will
> not return until the data is received, but the other party can never
> send it because it is also sat in the receiveBytes function.
>
> Here what happens is the core sends a locate command and calls
> receiveBytes waiting for a response.
>
> The viewer receives the locate command and flags this so that we
> capture the next mouse click, however before that happens the timer
> triggers the viewer to check for some more data, it calls receiveBytes
> then sits waiting for data. But of course the core won't send any data
> until it has received the locate data.
>
> The result is deadlock and the viewer hangs.
>
> The proper fix should be that there is an option in receiveBytes to
> return immediately if there is no data to grab. This option should
> always be used by the viewer to avoid both this kind of deadlock, but
> also to avoid hangs when the core is very busy - don't forget that the
> user program might be doing some very intense stuff in between
> plotting commands.
>
> Phil

Re: [Plplot-devel] Some remaining wxwidgets inefficiency concerns for examples 17 and 08

[Phil R. <p.d...@gm...>]

My best guess to this would be that every time new data is added to
the plot the wxPLViewer gets some new data and probably then calls
plreplot(). This then replots all the data from the beginning of the
stream including all the data that has previously been cleared and all
the clears. Whereas other plots probably just add the new data onto
the existing plot.

If this is the case then really the only fix for this inefficiency
would be an API change to allow plotting only part of a buffer or some
smart parsing of the buffer by plreplot to not render data before a
clear, but because clears are subpage specific and the current subpage
is not recorded anywhere this is a very large bit of work. In fact I
would go as far as suggesting that the amount of time that we would
spend resolving this issue might be orders of magnitude longer than
the total amount of time all our users would spend waiting because of
this inefficiency!

On 3 October 2017 at 08:05, Alan W. Irwin <ir...@be...> wrote:
> On 2017-10-03 00:20+0100 p.d...@gm... wrote:
>
>> Hi Alan
>>
>> Are those timing values from the console side or the viewer side?
>
>
> I failed to state how I measured time for the example 17 case but that
> was done essentially identically to what I stated for the example 8
> case, i.e., total time from start of example (core) to finish of all
> rendering.  So for new wxwidgets it is a combination of short core
> time plus long wxPLViewer rendering time, while for old wxwidgets it
> is total core time alone because wxPLViewer is irrelevant in that case
> (i.e., core does its own rendering).
>
> [out of order]
>>
>> I'm not sure what the cause is right now, but I'll run those examples
>> through a profiler and see.
>
>
> Thanks!
>
>
> 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
> __________________________

Re: [Plplot-devel] Slave displays

[Phil R. <p.d...@gm...>]

Yes I agree

On 3 October 2017 at 10:24, Alan W. Irwin <ir...@be...> 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
> __________________________

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
__________________________

Re: [Plplot-devel] Is it time to remove some IPC cruft from our wxwidgets-related code?

[Phil R. <p.d...@gm...>]

>
> It is good that you are doing some critical thinking about my bytes
> transmission logic this way.  However, it appears you are referring to
> the case where there are two separate but simultaneous uses of IPC
> (one to send an array of data from core to viewer and one to send an
> array of data from viewer to core).

Hi Alan
Actually I am talking about the opposite case. Both core and viewer
make a receive request. In both cases the receiveBytes function will
not return until the data is received, but the other party can never
send it because it is also sat in the receiveBytes function.

Here what happens is the core sends a locate command and calls
receiveBytes waiting for a response.

The viewer receives the locate command and flags this so that we
capture the next mouse click, however before that happens the timer
triggers the viewer to check for some more data, it calls receiveBytes
then sits waiting for data. But of course the core won't send any data
until it has received the locate data.

The result is deadlock and the viewer hangs.

The proper fix should be that there is an option in receiveBytes to
return immediately if there is no data to grab. This option should
always be used by the viewer to avoid both this kind of deadlock, but
also to avoid hangs when the core is very busy - don't forget that the
user program might be doing some very intense stuff in between
plotting commands.

Phil

Re: [Plplot-devel] Is it time to remove some IPC cruft from our wxwidgets-related code?

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

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

> Alan
> I have made a quick couple of changes that makes locate work correctly
> again with wxWidgets by simply halting checking for new data while
> doing a locate, then starting again when locate is complete.
>
> However I don't want to commit anything that may clash with any
> changes that you are making. Let me know if you have started making
> any changes in wxplframe in the wxPLViewer and if so I'll just send
> you a patch to avoid any clashes.

Hi Phil:

It is good that you think you have solved these locate issues (blank
display for both non-IPC3 (when PL_WXWIDGETS_IPC3 not #defined) and
IPC3 (when PL_WXWIDGETS_IPC3 #defined) code and no response to blind
mouse clicks for the IPC3 case).  I am not making any wxwidgets
changes at the moment because I had no idea how to solve these locate
issues and anything else I might do (getting keyboard key clicks to
work and code cleanup to get rid of non-IPC3 code) obviously should
come after these locate issues with display and mouse clicks are
solved.  So please go ahead and push your commit(s), and I will test
them on my Linux platform.

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
__________________________

Re: [Plplot-devel] Some remaining wxwidgets inefficiency concerns for examples 17 and 08

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

On 2017-10-03 00:20+0100 p.d...@gm... wrote:

> Hi Alan
>
> Are those timing values from the console side or the viewer side?

I failed to state how I measured time for the example 17 case but that
was done essentially identically to what I stated for the example 8
case, i.e., total time from start of example (core) to finish of all
rendering.  So for new wxwidgets it is a combination of short core
time plus long wxPLViewer rendering time, while for old wxwidgets it
is total core time alone because wxPLViewer is irrelevant in that case
(i.e., core does its own rendering).

[out of order]
> I'm not sure what the cause is right now, but I'll run those examples through a profiler and see.

Thanks!

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
__________________________

[Plplot-devel] Update of the Wiki: obsolete information?

[Arjen M. <Arj...@de...>]

Hi Alan, others,



I have updated the Wiki page on the status of PLplot for the Windows platforms. I noticed however that we list information about the Borland and Open Watcom compilers, as well as the CGM device. I have not seen any mention of the two compilers or of the CGM device for many years now. Is it really convenient to continue displaying that information?



By the way, I have added the newer languages to the overview and some of the newer components as well. I would appreciate comments - especially as far as the restrictions are concerned. If someone can point me to the missing components for Ocaml for instance or to a D compiler for Windows platforms, that would be great.



Regards,



Arjen



DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

[Plplot-devel] Further to your recent comment for wxwidgets gradient bug 173

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

Hi Phil:

In response to your remarks on the bug tracker for bug 173, I would like to
discuss this a bit more on plplot-devel with you, and once I get a full
education on this wxwidgets gradient subject from you I might add a
further comment to bug 173 on the bug tracker for future reference
(if anybody brings up this subject again).

Apparently the wxDC class (documented at
<http://docs.wxwidgets.org/3.1/classwx_d_c.html>) supports arbitrary
affine transformations (including rotations) now.  So it seems to me
that rotation of results from wxDC::GradientFillLinear could be used
to provide at least an arbitrarily rotated rectangular gradient result
to plgradient. That still leave the problem of dealing with the more
general case where the gradient was required for a non-rectangular
(arbitrary) polygon, but could that be handled by natively masking the
(possibly rotated) rectangular area with that polygon?  Or is such
native masking not available with the wxDC class?

Another possibility is wxGraphicsContext::CreateLinearGradientBrush
(documented at
<http://docs.wxwidgets.org/3.1/classwx_graphics_context.html>). I
don't understand how such a gradient brush would be applied, but
apparently there are no rectangular restrictions on it. Or is this
possibility completely shot down because the new wxwidgets code only
inherits from wxDC and not wxGraphicsContext so we have no access to
the CreateLinearGradientBrush method?

My final question is a general C++ one.  What syntax do I need to look
for to tell what wxWidgets library classes we inherit from?  I am pretty sure,
for example that

class wxPLDevice : public PlDevice

means our wxPLDevice class inherits from our PLDevice class.  But I
cannot find any equivalent syntax for what wxWidgets library classes
(such as wxDC or wxGraphicsContext above) we inherit from.

I would appreciate an answer to this question since that should allow
me to always know in the future exactly what wxWidgets library methods
are available to us.

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
__________________________

Re: [Plplot-devel] ocaml and antialiased gtk embedding (cairo)

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

On 2017-10-02 15:35-0000 Philippe STRAUSS via Plplot-devel wrote:

> Hello plplot devs,
> I'm an ocaml user using plplot in one of my pet project.The plcairo layer seems not usable anymore, what happened?

Hi Philippe:

Thanks very much for your interest in plcairo.

To answer your question above, I have reviewed the situation with git
blame and git log and the fundamental answer is the last two commits
by Hezekiah Carty before he took at least a temporary break from
developing PLplot in 2014 is he switched from the cairo to cairo2
OCaml module (commit 84d2a85) and followed up (commit e88308c) by
changing our OCaml documentation in presumably a compatible way with
that change.  Commit 84d2a85 was a substantial change, and here is the
associated commit message:

commit 84d2a859f31b69c1d440a7a61d5c57528de94355
Author: Hezekiah M. Carty <he...@0o...>
Date:   Thu Jul 3 14:46:13 2014 +0000

     Switch to a different OCaml Cairo binding ("cairo2" in opam)

     This is a more actively maintained binding to the Cairo library.  It is
     unfortunately not packaged for Debian at this time so interested users
     would need to install the library through opam.  opam is generally the
     recommended way to install and manage OCaml libraries (this cpan, pip, etc)
     so this isn't a particularly serious limitation.

     svn path=/trunk/; revision=13134

So the situation is I cannot test plcairo on our principal testing
platform (my Debian Jessie box), I am not even sure cairo2 will be
available once I upgrade that box to Debian Stretch, and despite Hez's
thought that opam might be the answer, I am reluctant to potentially
mess up my Debian installation with an opam installation on top of
that. Since we are stuck now and possibly in the forseeable future
with regard to testing plcairo and because Hez continues to be out of
touch, I ultimately decided to disable this capability (see commits
893625c and 84760038).  However, the net effect of those two changes
was extremely small so it should be absolutely straightforward to
resurrect plcairo again.  For example, you could do that
by reversing those two particular commits.

So given this background what do you recommend on the cairo versus
cairo2 question, and in particular do you know whether there is an
official Debian package that provides that cairo2 module?

Another possibility is I could go back to cairo from cairo2 by
reversing Hez's last two commits, but that would be a substantial
change so I would only do that if you recommend cairo over cairo2
these days.

Yet another possibility would be for PLplot to support an untested (by me)
cairo2 version plus a tested cairo version, but from the
size of commit 84d2a859f3 that would be a fair amount of work
to implement.

> I have some spare time to tackle the issue under guidance in case. I
use plplot embedded in a gtk windows from within ocaml like the
xgtk_interface example. I have ocaml cairo and cairo2 bindings.
regards.

Sounds good!  It appears by reversing my two small commits that you
might be in business with cairo2 right away, but regardless of that I
would appreciate the cairo/cairo2 advice I requested from you above,
and I would certainly be willing to help you with any CMake issues you
encounter and also apply your requested patches (if I have some
convenient way to test them).

Best wishes,

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
__________________________

Re: [Plplot-devel] Is it time to remove some IPC cruft from our wxwidgets-related code?

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

On 2017-10-02 21:22+0100 Phil Rosenberg wrote:

> Hi Alan
> I literally just logged onto my email to say stop whatever you are
> doing on this the locate mode is broken!!! :-D

Clearly, great minds think alike.  :-)  So indeed I plan
to retain the old IPC code for quite a bit longer (likely
to the start of the next release cycle in early 2018).

>
> 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.

It is good that you are doing some critical thinking about my bytes
transmission logic this way.  However, it appears you are referring to
the case where there are two separate but simultaneous uses of IPC
(one to send an array of data from core to viewer and one to send an
array of data from viewer to core).  But that simultanously use case
should be handled properly now.  Here is why. The TransmitSemaphore
(i.e., the m_tsem semaphore) is used to insure that the shared memory
can only be used to transmit one (possibly large) array of bytes at
any given time.  Any attempt to try sending a second array while a
first one is being transmitted just quietly pauses (see the early call
to m_threeSemaphores.waitTransmitSemaphore() in
PLMemoryMap::transmitBytes) until just before the return from the
first complete array transmission (see the late call to
m_threeSemaphores.postTransmitSemaphore() in
PLMemoryMap::transmitBytes).  Furthermore, once
PLMemoryMap::transmitBytes on the transmitting side in tandem with
PLMemoryMap::receiveBytes on the receiving side is allowed to actually
send data by the TransmitSemaphore, they use the ReadSemaphore and the
WriteSemaphore to make sure the entire transmission of all bytes in
the array via the (possibly smaller) shared memory area is completed
without deadlocks possible.  However, if you can come up with a
specific example where this logic could deadlock, more power to you,
but instead of introducing timed waits, I would prefer to fix it if
the deadlock is a bug in the implementation of the above design or
else redesign the above protocol for the transmission of an array of
bytes if that design is not correct.

> The receiveBytes functions needs a timeout otherwise it will hang the
> viewer if there is a problem at the other end.

Possibly.  With the new IPC3 approach I was admittedly on a mission to
eliminate as many timed waits as possible just to see if I could
reduce that number to zero.  As a result, if the users kills the core
with ctrl-C, the wxPLViewer continues and has to be independently
killed.  And the core hangs indefinitely in debug mode without a
timeout until the user does the correct suggested invocation of
wxPLViewer.  But in my opinion these issues are simply
convenience ones that we should deal with later after everything
(e.g., locate mode) works properly with the new IPC approach.

> 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.

OK.

> 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.

I agree that should be implemented once the mouse click part of it
(which is not #ifdefed out) works.  So as stated above I plan to
retain the old IPC code to act as a guide for the new IPC code for a
while longer.

In sum, I am hoping you indeed take this opportunity to look
critically at transmitBytes and receiveBytes with the aid of my
explanation to make sure you are satisfied they should "just work". Of
course, if you can imagine a scenario where they won't work (i.e.,
there could be a deadlock issue) I will fix them. However, my current
feeling is the real issue is not the details of how those routines are
implemented, but instead some other issue in the way that locate mode
is set up on the core side and/or viewer side for the new IPC method.
For example, a detailed comparison of what happens in locate mode for
the old IPC method versus the new one might reveal some critical
logical difference between the two code paths?  But I have looked at
all of that and could not find anything wrong so I hope your fresh set
of eyes, your much larger knowledge of exactly what triggers rendering
on the viewer side (which I have never understood and which does not
currently work properly for either IPC method), and/or your different
debugging methods will help spot and fix whatever the issue might be.

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
__________________________