Hi Phil:
I just ran
examples/c/x17c -dev wxwidgets
for the HEAD of master (commit 124a0c3), and I very much like that
that commit implements "interactive" look
for the new wxwidgets device as illustrated by this example.
However, the rendering is slow (i.e., 2.5
minutes) compared to the similar "interactive" plot you get with the
old wxwidgets device (which can be accessed using -DOLD_WXWIDGETS=ON
and which renders in 0.5 minutes). The xcairo device (which serves as
a good comparison because on this Linux platform wxwidgets is a
wrapper for the same pango/cairo suite of libraries that are used
directly for our cairo device driver) requires 0.9 minutes for this
same test and xwin requires only 0.2 minutes for this test. So there
is likely room to improve the efficiency of the xcairo device for this
example. But whatever approach the old wxwidgets device is taking for
example 17 certainly has reasonable efficiency, and the issue is to
get the new wxwidgets device driver to match that efficiency for
example 17. (Note that the old IPC method does not render example 17
with an interactive nature. I don't think we should worry about that
issue since that part of the code is headed to the dustbin. But it
does make efficiency comparisons between -DPL_WXWIDGETS_IPC3=ON and
OFF problematic for example 17).
To start the process of figuring out the source of this factor of five
inefficiency for example 17 for the new wxwidgets device (and new IPC
method) when compared with the old wxwidgets device, note that example
17 calls plstripa->plstrip_gen/plline a lot. So there are a very large
number of graphical line elements being rendered for this example.
In contrast, example 8 renders a lot of graphical fills, and
presumably because of that the pattern of inefficiency is different
for that example compared to example 17. For example 08, here are the
relevant timing results (as measured by the time it takes from the
launch of
examples/c/x08c -dev wxwidgets
to when wxPLViewer has completely rendered all pages of example 8 for
the new wxwidgets case (with either of the two IPC methods available
for that case) and when -dev wxwidgets has finished rendering in the
the old wxwidgets case).
1. Default configuration, new device with new IPC method:
-DOLD_WXWIDGETS=OFF -DPL_WXWIDGETS_IPC3=ON
32 seconds
2. New device with old IPC method: -DOLD_WXWIDGETS=OFF -DPL_WXWIDGETS_IPC3=OFF
33 seconds
3. Old device (no IPC required since -dev wxwidgets does its own
rendering in this case): -DOLD_WXWIDGETS=ON
32 seconds
4. xcairo device (which serves as a good comparison for wxwidgets speed
on Linux because the wxWidgets libraries are a wrapper for the pango/cairo
libraries
that our cairo device uses directly on that platform).
~3 seconds or less.
So in this x08c case, the first two results illustrate the new IPC
configuration is at least as efficient as the old IPC configuration (as
expected from all my other measurements concerning this issue), and
comparison of the first 3 results with the 4th result shows whatever
is causing this order of magnitude slowdown for this example compared
to xcairo is common to all wxwidgets configurations.
In sum, experimenting with how lines are rendered for new wxwidgets
versus old wxwidgets may help to figure out why new wxwidgets is so
slow compared to old wxwidgets for example 17, and experimenting with
how fills are rendered (likely in a similar way for both old and new
wxwidgets) when compared to xcairo or any other interactive device may
help to figure out why both the old and new versions of wxwidgets
render fills so slowly compared with other interactive devices for
example 8.
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
