Re: [ROOT] drawing speed in online monitoring

From: Pasha Murat (630)840-8237 FNAL (630)859-3463 home (murat@murat.fnal.gov)
Date: Sat Feb 17 2001 - 23:14:25 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. 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 : Tue Jan 01 2002 - 17:50:36 MET