Re: [ROOT] drawing speed in online monitoring

From: Valery Fine (fine@bnl.gov)
Date: Sun Feb 18 2001 - 02:26:17 MET


> my 2 cents: 
> 
> - I think that from the technical point of view the real issue is somewhat 
>   different from discussed in this thread: ROOT is using pixmap-based graphics 
>   rather than vector-based, so to redraw a line one flushes on the screen a
>   rectangle, containing this line, but not the line itself. 

  It is not correct.

  ROOT uses so-called "double-buffering" approach by default.
  This means it draws things first into some the "memory buffer" to create 
  the pixmap. Then the entire pixmap is used to override the screen pixmap 
  buffer.

  If the issue is the histograms only one can provide some optimized
  solution right away deriving the FastDrawingHistPainter from the 
  existent HistPainter.


  Fortunately one can turn off the double-buffering mode and draw things 
  to the screen buffer directly. This option is used to draw the 
  "rotation cube" for 3D objects.

  For the histograms one can image within the existent ROOT the scenario 
  as follows:

 Paint():
   1. Paint the histogram as the regular ROOT HistPainter does.

 Paint("update")

   2. Turn the "double buffering" mode  off
   3. "Erase" the "obsolete" piece of the histogram directly on the screen
   4. Add the "fresh" piece directly to the screen.

There are several underwater stones though. The main one. How the "painter" knows 
which piece of the histogram has become "obsolete". To address this question 
the painter must keep the copy of the histogram been drawn with the previous Paint 
step and compare it with the "present up-to-date" object. 
However even for the histogram it is not always as trivial as comparing two 
floating-point arrays.
  This problem has nothing to do with Qt PaintRectangle method whatsoever.
This method is useful if the object was NOT changed but the part of its 
screen view was destroyed. That corrupted part is defined by some rectangular 
area on the screen. It is not our case. In this case ROOT is efficient.

  Hope this  helps
                                          Valeri




Pixmap-based approach 
>   provides a lot of features very useful for high-level applications, however
>   for many simple ones (like histogramming, for example) it perfors
>   much, much slower. I'm still connecting to the lab over the 28K modem line 
>   with the latency of about 170ms (sorry, no DSL in the village) and while it 
>   is possible to run PAW remotely, performance of ROOT graphics over this line 
>   is well below any reasonable level.
> 
> - as for online performance, I don't see any problem here: specialized applications 
>   normally need specialized drawing methods. I.e. (as outlined by Valery) one can create a 
>   canvas with its list of primitives containing just one "view" object,
>   managing all the histograms displayed in this canvas and repainting them 
>   in smart way. Yes, it is some work, but nothing comes for free and in this case 
>   performance penalty paid would be at the level of repainting the whole window 
>   vs repainting one line... but JUST ONCE, meaning somewhat tens of milliseconds, 
>   but not seconds, per canvas..
>   best, Pasha
> 
> 
> Anton Fokin wrote:
> > 
> > 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