Re: [Plplot-devel] wingcc and wingdi build bugs

[Jim Dishaw]

> On Oct 4, 2017, at 3:26 PM, Alan W. Irwin  wrote:
> 
> 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?
> 

He was able to get the release to build according to his last message. I still 
need to work on the wingdi build for the environments that do not have the 
newer windows api calls. I need to spinup a VM running an older version of 
Windows to test. 

As for the big, that has to do with the pause mechanism and I have been waiting 
for the wxwidgets driver to stabilize. I’m going to make wingdi have the same 
behavior as wxwidgets relative to the pause. 

> 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

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

[Phil Rosenberg]



On 5 October 2017 at 00:38, Alan W. Irwin  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
> __

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

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

[Alan W. Irwin]

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
__

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

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

[Phil Rosenberg]

>
> 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 ;-)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] wingcc and wingdi build bugs

[Alan W. Irwin]

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
__

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

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

[Alan W. Irwin]

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


On 3 October 2017 at 18:00, Alan W. Irwin  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
__

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

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

[Alan W. Irwin]

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  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 testplfill test
IPC3 wxwidgets  26  seconds32  seconds
non-IPC3 wxwidgets  27  seconds32  seconds
old wxwidgets   18  seconds30  seconds
xcairo  1.4 seconds2.2 seconds
qtwidget1.5 seconds1.6 seconds
xwin9.5 seconds3.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

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

[Alan W. Irwin]

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 testplfill test
IPC3 wxwidgets  26  seconds32  seconds
non-IPC3 wxwidgets  27  seconds32  seconds
old wxwidgets   18  seconds30  seconds
xcairo  1.4 seconds2.2 seconds
qtwidget1.5 seconds1.6 seconds
xwin9.5 seconds3.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 

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

[Phil Rosenberg]

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  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
> Plplot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] xor mode and the buffer

[Phil Rosenberg]

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?

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] Fwd: Returned mail: see transcript for details

[Phil Rosenberg]

Resending as I got a wierd unable to deliver message - i tink some
email address confusion happend. see below

-- Forwarded message --
From: Phil Rosenberg 
To: "Alan W. Irwin" 
Cc: plplot_de...@beluga.phys.uvic.ca
Bcc:
Date: Wed, 4 Oct 2017 12:11:48 +0100
Subject: Re: Some remaining wxwidgets inefficiency concerns for
examples 17 and 08
On 4 October 2017 at 05:54, Alan W. Irwin  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 testplfill test
> IPC3 wxwidgets  26  seconds32  seconds
> non-IPC3 wxwidgets  27  seconds32  seconds
> old wxwidgets   18  seconds30  seconds
> xcairo  1.4 seconds2.2 seconds
> qtwidget1.5 seconds1.6 seconds
> xwin9.5 seconds3.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 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 

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

[Phil Rosenberg]

On 3 October 2017 at 22:01, 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.
>
> 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.

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

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

[Phil Rosenberg]

On 3 October 2017 at 18:00, Alan W. Irwin  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.

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