Re: [ROOT] Performance question: Updating a colz histogram

From: Faine, Valeri (fine@bnl.gov)
Date: Thu Oct 03 2002 - 18:29:39 MEST


----- Original Message -----
From: "Rene Brun" <brun@pcbrun.cern.ch>
To: "Valeri Fine" <fine@bnl.gov>
Cc: "'Ed Oltman'" <eoltman@imago.com>; "'Roottalk@Pcroot. Cern. Ch'"
<roottalk@pcroot.cern.ch>
Sent: Tuesday, October 01, 2002 5:05 PM
Subject: RE: [ROOT] Performance question: Updating a colz histogram


> Hi Valery,
>
> As already reported a few times, the solution to this problem
> is the new image processing class TASImage that has been introduced

Whatever,

His primray original object is 2D histogram and he still needs to convert
his 2D histogram to another representation to enojy any other solution.

It doesn't change the THIstpainter behavior, namely the time to draw 2D
histogram depends of the
cells occupancy and it grows.
It would be nice the very THistPainter class takes care about the optimal
way to draw the histogram
and choose TASImage whatever to optimize the drawing speed. For example when
the cell size
on the screen becomes less then 2 pixel there is no means to paint it with
the "full scale" box.

             Valeri

> in the version 3.03/09. Reiner Rohlfs will present this class
> and demos at the coming ROOT workshop.
>
> Rene Brun
>
> On Mon, 30 Sep 2002, Valeri Fine wrote:
>
> > Hello Ed,
> >
> > Thank you very much for the working example you sent me.
> > It made things much simpler to investigate.
> > Sorry for some delay.
> > I have investigated your code.
> >
> > > you able to duplicate the problem I was having (e.g. cpu time required
> > to
> > > redraw scatter plot grows as histogram gets more entries)?
> >
> > Yes I did.
> >
> > However your observation is not correct. It does grow but by the point.
> > Your 2D histogram is 500 x 500 bins = 250 000 bins.
> > Just try to define 50 x 50 to see what I am speaking about.
> > If you will define 100 x 100 you will realize the refresh time is
> > growing but it quickly becomes constant.
> > In fact the refresh time of 2D histogram should be proportional (at
> > least) to the number of non-zero cells of your 2D histogram. Since the
> > number of your non-zero cells is growing that refresh rate is going
> > down.
> >
> > I think the better performance can be provided via
> > TVirtualX::DrawCellArray.
> > However ROOT doesn't use it. This means each non-zero bin is drawn with
> > several dedicated calls to the low level graphics layer. That must slow
> > things down significantly.  Each bin is drawn as colored box. This means
> > to draw it the program has to set the current color pen and color brush
> > and then draw the filled box. To accomplish this it needs to call the
> > TVirtualX layer several times. To make things ever worse the low level
> > layer is called via 2 other intermediate layers.
> >
> >
> > See:
> > http://root.cern.ch/root/htmldoc/src/THistPainter.cxx.html#THistPainter:
> > PaintColorLevels
> >
> > In you case to refresh the picture ROOT calls up to 250'000 times:
> >
> >          fH->SetFillColor(gStyle->GetColorPalette(theColor));
> >          fH->TAttFill::Modify();
> >          gPad->PaintBox(xlow, ylow, xup, yup);
> >
> > You can see the algorithm of the THistPainter works well if the
> > occupancy of the cells is not high because it skips the empty cells. It
> > must degrade as soon as the occupancy of the cells grows (that's your
> > case)
> >
> > > > Is there something I could do to speed things up, short of adjusting
> > the
> > > > refresh rate?  I am using version 3.03/08 on Win32.  Thanks...
> >
> > At this point it would be reasonable to see whether you can use
> > TVirtualX::DrawCellArray methods. That will do everything in a single
> > call.
> > Be this reason one may expect the refresh time will be steady.
> > However this approach requires the custom THistPainter::PaintColorLevels
> >
> > method to be introduced.
> >
> > > Note 2: In addition to the 2D histogram, I also have a couple
> > > of 1-D histograms. [The object to display/update is selected
> > > at runtime.  All objects are filled all the time] The 1D
> > > histograms updating never slows down, only the 2D histograms
> >
> >   As I have explained the time to re-draw the histogram depends of the
> > number of the bins to be drawn,
> >   Your 1D histogram contains 600 bins. This is nothing against of
> > 250'000 bins of your 2D histogram.
> >
> >    Hope this helps. My best regards, Valeri
> >
> >
> >
> > > -----Original Message-----
> > > From: Ed Oltman [mailto:eoltman@imago.com]
> > > Sent: Tuesday, September 03, 2002 9:35 AM
> > > To: fine@bnl.gov; 'Roottalk@Pcroot. Cern. Ch'
> > > Subject: RE: [ROOT] Performance question: Updating a colz histogram
> > >
> > > Valeri,
> > >  Here are some more details (not in order asked)
> > >
> > > 2. I had the same problem in V 3.02/7 as well as 3.03/8
> > >
> > > 4. I am using a standalone root based application - e.g. I
> > >    create an instance of TRint.  The application is an MFC
> > >    SDI application where I took special pains to wrap the
> > >    root stuff in its own class that does not have #include
> > >    "stdafx.h" or any other windows/mfc stuff.
> > >
> > > 1. My application's view class has an OnTimer() method
> > >    which in turn calls p2DH->Draw("colz") and
> > >    gPad->GetCanvas()->Update().
> > >
> > > 3. If you like, I could make a small mfc project that
> > >    displays the problem I'm having.
> > >
> > > Note: you mention in subsequent e-mail that it is not
> > > necessary to call the Draw() method each time.  If I do
> > > not call the Draw() method each time, nothing gets displayed.
> > >
> > > Note: The histogram is filled in a different thread than
> > > it is displayed.  I use a win32 semaphore to protect the
> > > object's filling with its display.
> > >
> > > Note 2: In addition to the 2D histogram, I also have a couple
> > > of 1-D histograms. [The object to display/update is seleceted
> > > at runtime.  All objects are filled all the time] The 1D
> > > histograms updating never slows down, only the 2D histograms
> > >
> > > Ed Oltman
> > >
> > > > -----Original Message-----
> > > > From: Valeri Fine [mailto:fine@bnl.gov]
> > > > Sent: Friday, August 30, 2002 5:31 PM
> > > > To: 'Ed Oltman'; 'Roottalk@Pcroot. Cern. Ch'
> > > > Subject: RE: [ROOT] Performance question: Updating a colz histogram
> > > >
> > > >
> > > > Hello Ed,
> > > >  Sorry, you didn't send an example to reproduce your troubles so I
> > have
> > > > to ask you some extra questions:
> > > >
> > > >    1. What kind of timer do you use: synch or asynch ?
> > > >    2. Did you see this problem before (with the previous version of
> > > > ROOT) ?
> > > >    3. Can you work out a small macro / code to reproduce the problem
> > ?
> > > >    4. Do you use "ROOT + macro"; "Root + your custom DLL"; your
> > > > ROOT-based application alone ?
> > > >
> > > >   Thank you
> > > >               Valeri
> > > >
> > > > -----Original Message-----
> > > > From: owner-roottalk@pcroot.cern.ch
> > > > [mailto:owner-roottalk@pcroot.cern.ch] On Behalf Of Ed Oltman
> > > > Sent: Friday, August 30, 2002 5:35 PM
> > > > To: Roottalk@Pcroot. Cern. Ch
> > > > Subject: [ROOT] Performance question: Updating a colz histogram
> > > >
> > > > Hello,
> > > >  I have an online application which includes a 500x500 bin TH2F
> > which I
> > > > display in response to a timer with
> > > >
> > > >     p2DH->Draw("colz");
> > > >     gPad->GetCanvas()->Update();
> > > >
> > > > (I've previously called gStyle->SetPalette(1,0))  Early on, when the
> > > > histogram is still young, the refresh is pretty quick - refreshing
> > at 2
> > > > Hz
> > > > uses a small amount (<10%) of the cpu time. Gradually, as the
> > histogram
> > > > fills, the refresh time increases - by the time the histogram has a
> > few
> > > > hundred thousand entries, (maximum bin contents is in the 10s) the
> > cpu
> > > > time
> > > > is 80% and climing.
> > > >
> > > >
> > > > Ed Oltman
> > > >
> > > >
> > > >
> > > >
> > > >
> >
>



This archive was generated by hypermail 2b29 : Sat Jan 04 2003 - 23:51:12 MET