Severe problem with TGraph

Dear Rooters

Currently, I am testing my GUI application with real data, and
found the following problem: When trying to draw a simple graph
my program crashes with the following message:

*** Break *** write on a pipe with no one to read it
Error in : fatal X11 error (connection to server lost?!)

**** Save data and exit application ****

Thus I created the attached simple macro “macroGraph.C”.

When using n=200000 everything works fine, but when I set n=2000000
then I get a segmentation violation:
root [0] .L macroGraph.C+
root [1] Graph()

*** Break *** segmentation violation
Root >

Is this a known problem of TGraph?

P.S.:I am using the CVS version of root from 10 February 2005 on MacOS X.

Best regards
Christian
macroGraph.C (1.27 KB)

Christian,

I cannot reproduce this problem on Linux or Windows.
Fons will check on MAC

Rene

Hi,
sounds like the deadly polygon http://root.cern.ch/phpBB2/viewtopic.php?t=1101 is hitting us again. X11 mallocs from stack, and runs into problems when the polygon to be drawn takes up more space than the stack size has to offer.
Axel.

Dear Rene

Thank you for your fast reply.
Since you cannot reproduce this problem on Linux or Windows, I
would be interested if other Mac users can reproduce my problem.

Dear Axel

Thank you for this likely explanation, but Rene should then be able
to reproduce my problem on Linux?

I tested your code:
TH1D h
h.SetBins(5000000, 0, 1)
h.Draw()
and get exactly the same error message as with my application.

What I do not quite understand is:
In my app I am abusing TH2D to create a 2-dimensional image of
size 1164*1164 from a vector img of length 1354896:

   nrows = 1164;
   ncols = 1164;
   TH2D *h2 = new TH2D("H2","Title",ncols,0,ncols,nrows,0,nrows);
      for (Int_t i=0; i<ncols; i++) {
         for (Int_t j=0; j<nrows; j++) {
            h2->SetCellContent(i+1, j+1, img[i*nrows+j]);
         }
      }
   h2->Draw(opt); 

This works pretty well, but using the same vector img to draw
1354896 points with TGraph results in the mentioned crash!

BTW, limiting the number of points to be drawn as you suggest for
the number of bins is no solution, because users expect to be able
to draw a graph or scatterplot from data of such size.

Best regards
Christian

Hi Cristian,

what Axel says is correct. It is a problem with very large single graphics primitives that cause the X11 system to barf. In the TH2D case the drawing results in many smaller X11 drawing requests so there is no problem. The solution would be for the ROOT graphics system to break these large single primitives into several smaller ones. The irony is that originally we had code that did this but it got lost in some optimization overhaul of the TGX11 class and it has been broken since (at least 4-5 years already).

I was hit by it once drawing very large filled time spectra (many thousands of bins). When drawing non filled objects it is simple to break up the request of a single large XDrawLines() into a number of smaller XDrawLines() but splitting up a filled polygon is a bit more work altough in the special case of a histogram with a convex shape it is also fairly easy. To be fixed.

Cheers, Fons.

Hi Christian,

The reason that histograms have no problems but graphs could be that 6 years ago special code was added to
void TGraph::PaintGrapHist to handle painting of histograms with huge
amount of bins , it starts around line 2980, follow the word “lowRes” .

The idea is that there is no point in plotting data with higher resolution
than the resolution of the output device . So determine the number
of pixels in the current pad, and lookup for each pixel in x the range
covered in y . Now draw a vertical line from pixel ymin to ymax . This
idea can only be applied to standard histograms, no filling .

It should be applicable also to standard graphs of the from y=f(x),
no contours, no filling etc .

Eddy

ps. Your little TH1D example does not work because in the last 6 years
the default for a histogram is to have a fill color, which results in not
applying the special algorithm .
Solution here is to do h.SetFillColor(0);

But of course we still need to fix this for filled objects are automatically switch to non-filled and printing a warning.

– Fons

Dear Fons, dear Eddy

Thank you for this extensive explanation.

It is a pity that it does not work. At least, a warning should be printed,
as Fons mentioned.

BTW, in my real app I do not have a standard graph y=f(x), but a scatterplot,
where I need to draw 2 million points, so I am afraid that the mentioned
solution might not work?

Best regards
Christian

Christian said:

I saw also this problem on my linux machine. This was due to a wrong initialisation of the default histogram fill color which, later on, trigered the histogram drawing as a filled area instead of a polyline. This is now fixed in the cvs head. Note that if you used an other constructor than the default one (for TH1D) it worked.