Hi ROOTERS
Is it possible to use the opengl external viewer when plotting a TH2D (with lego2 option for instance) or a TH3D histogram? I tried the “ogl” option as described in the manual but it seems to work only with geometries.
The problem is that I have histograms with a lot of bins and with the gl-in-pad method, with no hardware acceleration, it is very slow.
Thanks.
See the example in $ROOTSYS/tutorials/gl
glbox.C
glsurfaces.C
gltf3.C
I know about those exampels and until now it is how I used to plot 3D histograms in a pad. This is what the manual call “gl-in-pad” because it uses the ROOT pad and opengl. But when the graph starts to be complex, it is very slow. As an example, I have a TH3F histogram with roughtly 200x200x40 bins (not that much by the way , compare to what graphics cards can do nowadays) and just the time for display is awful. And forget about interacting with it.
For what I understand, this is because, the gl-in-pad doesn’t use hardware acceleration, it uses only CPU for rendering, not the GPU.
On the other hand, there is the “external” viewer, the so call “Root GL viewer”. This is the viewer used in tutorials/geom. This one is very fast, probably because it uses hardware acceleration. It can handle complex geometries like Alice detector without problem. But it seems to handle only geometries, not histograms (or TGraph2D…)
So the question is: is there a way to use this viewer instead of the pad so I can benefit hardware acceleration? I guess the answer is probably “not yet” or “wait until the pad has hardware acceleration” (in ROOT 2007 workshop, a collaboration showed us a pad with hardware acceleration).
Thanks
[quote]I know about those exampels and until now it is how I used to plot 3D histograms in a pad. This is what the manual call “gl-in-pad” because it uses the ROOT pad and opengl. But when the graph starts to be complex, it is very slow. As an example, I have a TH3F histogram with roughtly 200x200x40 bins (not that much by the way , compare to what graphics cards can do nowadays) and just the time for display is awful. And forget about interacting with it.
For what I understand, this is because, the gl-in-pad doesn’t use hardware acceleration, it uses only CPU for rendering, not the GPU.
[/quote]
No, you are wrong. gl-in-pad uses hardware acceleration, but in a bit non-trivial way: since gl-scene should be painted inside usuall pad (TPad), I had to do some tricks. TCanvas/TPad with gl enabled has window with specific pixelformat.
GL draws into back buffer, frame-buffer content
is read back, converted into DIB/XImage/pixmap, standard X11/Win32 GDI can now draw into this pixmap/DIB (axes and labels for histogramm), and now standard pad can use this pixmap/dib - flush, copy etc.
So, because of TPad/TCanvas/TVirtualX/roots_2d_primitives architecture I have several “redundant”, probably very expensive read/copy operations instead of standard double buffered GL.
Yes it’s slow and I have strange feeling it was faster before - I could, for example, rotate and select in 100x100 lego before and it was smooth and fast, but it’s not now.
That’s why right now we’re (we == me and Matevz Tadel) working on “real” gl pad - which will be free from TPad/TCanvas+GL limitations.
It works OK with lego and surfaces, but I’m not sure about TH3. Probably, Matevz can answer.
