RE: [ROOT] drawing speed in online monitoring

From: Anton Fokin (anton.fokin@smartquant.com)
Date: Sat Feb 17 2001 - 22:06:15 MET


Hi Valery,

ROOT has only ::Paint methods which basically redraw everything. In Qt, for
example, each class provides PaintRectangle method and this improves the
performance a lot in case you need to repaint only a part of an object.

There is also a brutal way to introduce histogram behavior I discussed in my
previous mail: make TBin class and consider a histogram as a collection of
TBins. TBin class knows how to redraw itself, etc. In this case
TH2::Fill(x,y,1) triggers (x,y) bin and only this bin will be redrawn.

In fact I think that if a low-level facility can paint (set) one pixel on a
screen, all the problems are solved...

I also think it is a bit strange to repaint/recalculate the whole complex
object like TH2 if only one bin needs to be repainted.

Regards,
Anton


-----

 I don't think what you are talking about is a kind of the
"improvement". This does change the low level ROOT design
.
The main idea (as I understand it) is to minimize the dependency
of the current operating system / graphics layer. As result ROOT
(as its parent HIGZ) requires very few simplest graphics features.

The main ROOT idea is TPad keeps the list of the original objects those
paint themselves via virtual TVirtualPAd::Paint() method.

To implement what you are speaking about this model should be changed.
Namely instead of the list of objects TPad must be in possession of the
instance of the "helper" / "proxy ??" class objects for the objects one
wants
to be drawn.

This means to be able to optimize drawing the way you propose
the author of the class has to provide another "helper" class rather
the MyClass::Paint method. In fact it is very way Microsoft Foundation
Classes are designed.

"de Facto" ROOT team has adopted such approach for some classes
like  THxx and TNtuple introducing so-called "painters"
However this is a kind of patch that doesn't change the original schema.

Each scheme has its own pro and cons.

The current schema works well when one needs to play with many different
kind
of classes and wants  implementing things quickly.

"Microsoft" schema works better when the number of classes is restricted
and one wants optimize drawing to many different real hardware devices.

One can find this approach within ROOT 3D graphics classes. There
one has to create the list of 3D objects to be draw and then select some
particular rendering method: X3D, OpenGL, Open Inventor.

For each type of the 3D rendering ROOT creates a special "view" objects.
As result the concrete viewer is provided with objects optimized for this
particular viewer. But it loses the capability to represent the arbitrary
class object. Only "known" 3D objects can be drawn.

http://www.smartquant.com



This archive was generated by hypermail 2b29 : Fri Jun 08 2001 - 11:51:10 MEST