Werner,
The main reason why the Qt driver works that way is just an inheritance
of its origins in our QSAS software. In this software, we don't need
animation, and we only rely on Qt to do the plotting when it has time to
do so. Qt allows to either call an immediate replot or schedule a replot
"when it has time to do so". We chose the latter. We could not just plot
on a canvas in memory and display it, as we want to be able to rescale
the window and the plot without losing precision. So we store the plot
in memory as a commands buffer rather than a canvas.
But now I will have to make the driver evolve so that I can update only
the changed part of the plot, as you suggest, but I think slightly
differently.
Alban
Werner Smekal wrote:
> 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
