Hi Alban,
I actually don't understand why you need to "replot" everything. In
the wxWidgets driver I draw into a memory canvas and from time to time
I copy the canvas to the screen, so that the user can see how the plot
evolves. This makes the driver slower but a little bit nicer to look
at and example 17 works right away for that reason (Maybe I only
update the screen if there is a flush, this would improve speed and
give the user control about the plot update - I didn't know about this
function). In addition to make the plot faster, I only copy the parts
of the memory canvas which were changed to the screen. If this is of
any help to you, I use the method wxPLDevBase::AddtoClipRegion() for
that, which determines the minimal size of the region which must be
copied. wxWidgets on its own provides similar functionality but back
then I wasn't successful in using that.
HTH,
Werner
On Aug 22, 2009, at 9:38 AM, Rochel, Alban wrote:
> 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
--
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria
DVR-Nr: 0005886
email: sme...@iap.tuwien.ac.at
web: http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office)
+43-(0)1-58801-13469 (laboratory)
fax: +43-(0)1-58801-13499
------------------------------------------------------------------------------
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
