Hello 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. This is to say to > to promote ROOT in the on-line world. > The rule of on-line displays is : update only what has been changed, leave > the rest untouched, don't waste time. one has to implement "Document" / "Document view" approach. As usually the MAIN problem is to match "cross platform approach". That I do not know "right good for all" solution. I see no big technical problem to implement this for Windows only I do not know may be we need a separate forum to discuss such sort of things rather the current "roottalk". Valeri ----- Original Message ----- From: Anton Fokin <anton.fokin@smartquant.com> To: roottalk <roottalk@pcroot.cern.ch> Cc: Rene Brun <Rene.Brun@cern.ch>; Fons Rademakers <Fons.Rademakers@cern.ch>; <buskulic@lapp.in2p3.fr>; Eddy Offermann <eddy@rentec.com> Sent: 17 февраля 2001 г. 7:01 Subject: RE: [ROOT] drawing speed in online monitoring > Hi guys, > > Although I suppose to be a banker, I am stilll working with on-line DAQ > applications based on ROOT :) So here are a few words about ROOT on-line > performance. > > Well, my statement is: at present ROOT is not optimized for on-line data > taking/displaying, although works reasonably well in such applications in > general. > > An example: > > What we typically do in DAQ/on-line applications: > > - collect N events > - update a set of 256x256 2D COLZ histograms in a canvas > > Easy. Practically it means several H->Fill(x, y, 1); calls before a > graphical update. The point is that on the average you increase only > several bins out of millions. Most likely these bins do not go above max of > a histogram, so that COLZ scheme stays the same and only those several bins > change colors (or not). > > So.. instead of updating only a few point in a canvas, ROOT recalculates all > COLZ levels and redraws all histograms. Consequently instead of a few > milliseconds you spend tens of seconds for one screen update. > > I understand that a smart on-line update requires a number of improvements, > but this is somehow a must if you want to promote ROOT in the on-line world. > The rule of on-line displays is : update only what has been changed, leave > the rest untouched, don't waste time. > > Regards, > Anton > > http://www.smartquant.com > > > >
This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:50:36 MET