On 2015-06-20 11:46+0100 Phil Rosenberg wrote: > Regarding the speed on Linux.I have a problem which I will describe > below with my Ubuntu machine, but I have just quickly tested example 3 > with ssh over the internet connecting to my work CentOS PC. I think > was the example you used to highlight the problem. On Windows it takes > about 3 seconds from selecting the wxWidgets driver and pressing enter > to running the wxViewer and displaying the plot. By comparison the ssh > over the internet test takes about 10 seconds. 6 of those seconds are > the time up to the window being initially displayed so they are > probably the time required to load the executable and for wxWidgets to > do its initial window setup. This leaves about 4 seconds to transfer > the data to wxViewer and render. While I agree that this isn't > brilliant, given all the extra overheads going on with that connection > I think that is acceptable. What sort of rendering times do you see > running on an actual Linux machine?
Hi Phil: I did some timing tests for 5.11.0 for comparison purposes which you should be able to replicate at least in part (the wxwidgets part) on your own Linux boxes. In each case after building x00c (one of the simplest examples), wxwidgets, and other device drivers I ran time examples/c/x00c -dev <device> -np twice (where I used the second timing result since that tends to be more reliable with everything required loaded from disk into memory for that second try) for device = wxwidgets, xcairo, qtwidget, and xwin. The 5.11.0 results when run directly on my principal box (no ssh) were wxwidgets: real 0m0.421s user 0m0.032s sys 0m0.036s In this (5.11.0) case, the -np option is ignored (I think), but the wxPLViewer app seems to disconnect as soon as the page is displayed so the above time corresponds pretty closely to the time required to display that one page example. xcairo: real 0m0.163s user 0m0.016s sys 0m0.008s qtwidget: real 0m0.323s user 0m0.060s sys 0m0.024s xwin: real 0m0.097s user 0m0.004s sys 0m0.000s If I did the same timing tests from a thin client over ssh, the times went up by roughly a factor of two, and in no case did the time exceed 1 second for any of these devices. In sum, wxwidgets is a bit slow for 5.11.0, but still acceptable in comparison with other heavy-duty interactive devices, and all of those heavy-duty ones are substantially slower than -dev xwin. I also tested the current (2db68f6 Impliment use of nopause in the wxWidgets driver) master tip in the same way for the direct method of display. The timing results were similar (as expected) for xcairo, qtwidget, and xwin. However, the command time examples/c/x00c -dev wxwidgets -np ended up with the wxPLViewer application frozen with no signs of life for up to 30 seconds before I gave up and killed it. If this test works for you on Windows and also your CentOS box then you should double check that you are really testing commit 2db68f6 rather than some local version with added changes, and if you are, perhaps this issue is due to some wxWidgets version issue? (I am currently testing the Debian wheezy version 2.8.12.1-12 of WxWidgets.) Anyhow, I am anxious to complete the timing test on Linux for master tip -dev wxwidgets once you can figure out how to unfreeze the wxPLViewer application for my version of WxWidgets. In any case you should be doing similar timing tests yourself between master tip and 5.11.0 on the Windows and CentOS boxes accessible to you to make sure there have been no serious timing regressions introduced during the current release cycle for our wxwidgets device driver. (The additional timing results I reported above for the xcairo, qtwidget, and xwin devices are just to give context for these wxwidgets timing results, and there is no necessity for you to time any device other than wxwidgets on your various boxes for 5.11.0 and master tip.) 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 mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
