Hello Alan,

I am well aware that repaint is the bottleneck. What repaint does is ultimately 
to call QtPLWidget::plot() (via QtPLWidget::paintEvent()). Plot() does replay 
the whole buffer, it was never designed to be "region-aware". So no matter what 
region/rectangle is given to the overloaded repaint(...), everything would be 
redrawn.

An easy way to fix that would be to allow it to draw within a QRegion mask 
only, using QPainter::clipRegion. And I believe this would improve performance. 
However, I think we can do better than this as:
- The whole buffer would be unrolled anyway, only the actual painting would be 
clipped
- we would have the overhead of updating the region at every line, polyline, 
polygon command received from PLplot.

The solution I propose is to keep in memory an iterator ("pointer") to the last 
plotted element in the memory buffer, at each plot() call. This costs very 
little, and would allow to unroll and draw only the part of the buffer that has 
been added since the last flush(). No region merging, no clipping tests, just 
flushing what has not been flushed yet.

I haven't tried any of the solutions yet and I may realise that my approach is 
not feasible or harder than I expect, but I believe this would be faster in the 
end.

Alban

________________________________________
De : Alan W. Irwin [ir...@beluga.phys.uvic.ca]
Date d'envoi : vendredi 21 août 2009 23:31
À : Rochel, Alban; Andrew Ross
Cc : PLplot development list
Objet : Re: [Plplot-devel] Qt driver update

Alban said:

> As for your suggestion of using an overloaded repaint(), I'm afraid it's
not that easy, as any call to the plot function will cause the whole buffer
to be "replayed" anyway.

I did an experiment replacing the call to repaint() by a call to update().
The result was that example 17 with -dev qtwidget was as fast as with -dev
xwin.  Of course, you lose all animation then and only get a snapshot of the
last completed result because unlike repaint (which is specifically for the
animation case), update drops intermediate results.  So to me that
experiment proves repaint is the sole bottleneck that causes the animation
speed issue (at least with the present design).

I don't understand your argument above concerning replaying the whole buffer
since the whole point of repainting just the relevant rectangle is to avoid
changing anything else in the plot that is displayed. Thus, it seems to me
if you use the overloaded variation of repaint supplied by Qt4 that only
repaints what has changed (i.e., it limits itself to just a small rectangle
that you specify when there is only one added point) the result has to be a
lot faster.  However, you know a lot more about Qt4 than I do so if I am
missing something (and repainting a small region is no faster than
repainting the whole plot) please explain where my analysis is going wrong.

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
__________________________

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

Reply via email to