Hi Alban,
> 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.
In case of resizing I use the plplot replot() function. Plplot on it's
own buffers all called functions and you can recall them on demand. So
in case of resize I delete the memory buffer, allocated a new one,
replot everything using the PLplot replot() function and copy the
memory buffer to the screen. I didn't know that you have your own
command buffer.
>
> 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.
Sure, I just wanted to point out how it's done in other drivers.
All the best,
Werner
>
> 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
>>
>>
>
--
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria
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
