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