Alan W. Irwin wrote: > On 2009-07-31 11:49+0100 Alban Rochel wrote: > > I have recently been doing some interactive testing, and I have to comment > on the outstanding speed obtained with the new version of qtwidget. Here are > some timing comparisons for example 8, but other examples also show these > type of qualitative results. > > softw...@raven> time c/x08c -dev xwin > > real 0m0.769s > user 0m0.152s > sys 0m0.072s > > softw...@raven> time c/x08c -dev qtwidget > > real 0m0.974s > user 0m0.624s > sys 0m0.016s > > softw...@raven> time c/x08c -dev xcairo > > real 0m3.031s > user 0m1.232s > sys 0m0.084s > > I held down the enter key to autorepeat as rapidly as possible through the > various pages of the example in each case so I believe the "real" times are > reliable even though in each case they are substantially larger than the sum > of user + sys time (presumably because of different waits for system > resources required by the three different methods used here for generating > the results). > > Focussing just on the real times, the qtwidget speed is outstanding > considering all the extra font rendering and antialiasing work it does to > make nice looking results compared to -dev xwin in roughly the same amount > of time. -dev xcairo has similar nice looking results as qtwidget, but it > takes roughly three times longer to render the result. That's interesting, > but I don't think that is a major xcairo concern since I believe developers > should not optimize unless there is an order of magnitude or so to be > gained, and that is clearly not the case here. > > I was curious about the speed of qtwidget in the old days and here is > one result I posted to this list in late April. > > softw...@raven> time c/x08c -dev qtwidget > > real 0m5.423s > user 0m3.432s > sys 0m0.132s > > Obviously, there has been more than 5 times improvement in qtwidget speed > since then. Thanks, Alban! > > 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); PLplot scientific plotting software > package (plplot.org); 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 > __________________________ > Alan,
Thanks for this analysis, it's good to see that the driver is roughly on par with if not faster than others. I've measured improvements up to 40 times on spectrograms (thousands of rectangles), and interestingly the speed gains were greater on Windows than on Linux (on my test systems). As I mentioned, part of this gain was due to using x/y rectangle primitives rather than polygons where applicable. I believe most drivers could gain speed if PLplot provided a plfillrect function for such primitives. For example, plimage ends up calling plfill to create hundreds of polygons which are finally rectangles, which could be handled much faster than plain polygons. Just an idea, I don't know if it would be worth the effort, and I may have overlooked some issues. Cheers, Albam ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Plplot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/plplot-devel
