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