To summarize http://root.cern.ch/root/HowtoDraw.html: 1) object->Draw() adds a reference to object in list of primitives of current pad, but it does not draw directly. It builds a display list. 2) object->Paint() is called when pad is being Updated(). Here the actual painting is being done. 3) the same object can be drawn in different pads. In that case there are no multiple copies of the same object, only multiple references to the same object. 4) if an object gets deleted its references will be recusively removed from all pads via the call gROOT->GetListOfCanvases()->RecursiveRemove(this) in the ~TObject (see source on web). The nice thing of this approach is that what you see on the screen is the real object and not a copy of it. Also it is quite efficient compared to systems where, e.g. the histogramming, is separated from the drawing. Most of those systems need two copies of an object (the histogram object and a separate display list structure). Cheers, Fons. Pasha Murat wrote: > > > > > How it is possible to draw a DriftChamber thing on the screen w/o allocating > > dynamically an object per graphics primitive, but having > > DRIFT_CHAMBER::Draw method drawing all of them? > > ROOT's "how to Draw objects" + source code answer this question: > user has to provide UsersObject::Draw method which doesn't draw > anything and UsersObject::Paint method which does drawing by > using TPad::DrawPrimitive > (Primitive here stands for Line, Polyline etc). An code example > would be extremely helpful here, because in all the tutorials > only Draw method is used... (I have to admit that "Draw" is far > from being the best name for the function which appends a pointer > to one object to another one) > > BTW, we have a potential problem here. > If the same object is displayed in 2 windows (for example, default > and zoomed views) user has to care about having 2 different copies > of the same object - otherwise the same pointer will be deleted > twice when both windows are closed... > > This problem could be solved by introducing a class (say, TPointer) > describing a smart pointer which would > know whether it has actually been allocated and therefore should be > deleted by the destructor or it just clones already allocated pointer > so delete operator should not be called for it? > > May be a class providing this functionality already exists but has > a name which doesn't tell it? > > Regards, Pasha. -- Org: CERN, European Laboratory for Particle Physics. Mail: 1211 Geneve 23, Switzerland Phone: +41 22 7679248 E-Mail: Fons.Rademakers@cern.ch Fax: +41 22 7677910
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:26:21 MET