From: Alan W. I. <ir...@be...> - 2017-10-02 21:03:11
|
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 __________________________ |