CanvasPreferGL with COLZ

Dear ROOT experts,

The plots below contain two identical histograms plotted in the same style.

The only difference is the following line in the .rootrc file:

# .rootrc
OpenGL.CanvasPreferGL: 1

Left histogram with the option OFF
Right histogram with the option ON.

Why do they look so different!, especially in the areas of low multiplicity?
Which representation is more correct and why?

Some style info probably of most relevance:

ROOT.gStyle.SetPalette(ROOT.kBird)
ROOT.gStyle.SetNumberContours(256)
ROOT.gStyle.SetPadLeftMargin( 0.6 * 0.33 )
ROOT.gStyle.SetPadRightMargin( (1 - 0.6) * 0.33 )
ROOT.gStyle.SetPadBottomMargin(0.65 * 0.33)
ROOT.gStyle.SetPadTopMargin( (1 - 0.65) * 0.33)
canvas = ROOT.TCanvas("c", "c", 600, 600)
# histograms are (1000x1000 bins) 

I have tried newer versions of ROOT, and it looks like the plot is on the right.
Looking at this difference, I cannot switch to a newer version of ROOT graphics and keep all my plots consistent with the ones created with the previous ROOT version created with identical data…

ROOT Version: 6.28

Hi Bohdan,

Thanks for the interesting post!
I let the graphics experts, @linev and @couet , comment in detail about the change in the visualisation outcome.

Cheers,
Danilo

I cannot see a such difference with the histograms I have. Can you post a macro reproducing this issue ?

Hi @couet,

Environment

source /cvmfs/sft-nightlies.cern.ch/lcg/views/dev3/Mon/x86_64-centos7-gcc11-dbg/setup.sh

ROOT Version: 6.31/01
Built for linuxx8664gcc on Feb 18 2024, 23:48:19
From heads/master@v6-31-01-1074-g8545c24

OS: CentOS Linux release 7.9.2009 (Core)

Reproducible

// bug_CanvasPreferGL.cpp
void bug_CanvasPreferGL(){
    gStyle->SetPalette(kBird);
    gStyle->SetNumberContours(256);
    auto margin = 0.33;
    auto leftMarginRatio = 0.6;
    auto bottomMarginRatio = 0.65;
    gStyle->SetPadLeftMargin( leftMarginRatio * margin );
    gStyle->SetPadRightMargin( (1 - leftMarginRatio) * margin );
    gStyle->SetPadBottomMargin( bottomMarginRatio * margin );
    gStyle->SetPadTopMargin( (1 - bottomMarginRatio) * margin);

    auto canvas = TCanvas("c", "c", 600, 600);
    auto h = new TH2F("h", "title;x;y", 1000, -5, 5, 1000, -5, 5);
    auto func = new TF2("func", "exp(-0.5*(x)**2) * exp(-0.5*(y)**2)");
    h->FillRandom("func", 1e7);
    h->Draw("COLZ");
    canvas.SetLogz();
    canvas.Update();
    gPad->WaitPrimitive();
}

Execute as

root bug_CanvasPreferGL.cpp

.rootrc version 1 (gives the left plot)

#.rootrc
# OpenGL.CanvasPreferGL: 1
Canvas.Name: TRootCanvas

.rootrc version 2 (gives the right plot)

#.rootrc
OpenGL.CanvasPreferGL: 1
Canvas.Name: TRootCanvas

EDIT:
I’ve updated the plots. I still had some style setup in the .rootlogon.C.
I’ve commented .rootlogon.C to completely reset the style to the default.

Thanks @FoxWise

I see the same effect on Mac:

The two plots do look the same. If we turn off the log scale it is also visible. I do not have an answer yet but I suspect something connected to the number of bins of your histogram:

  1. Your cannas size is 600x600
  2. Your histogram has 1000x1000 bins.

As your histogram does not cover the full canvas it means you are trying to represent 2 bins per pixel ! as you can imagine that’s not really feasible, and it is not really surprising that two different graphics backends do not produce exactly the same outputs (because of rounding etc).

1 Like

On linux, with ROOT 6.30/04 I also get different results with and without GL if the canvas is saved as PNG (and I suppose other raster formats), but saving as PDF both versions look the same. So it appears to be a ‘scaling’ issue indeed (more bins than pixels).
With the latest development version (6.31/01), even the PNG versions look the same, so this seems changed for next releases.

When you go to PDF the same backend is use in both cases. That’s why you get the same picture.
I get the different image on screen on Mac ith master. As I said, with 2 bin per pixel it is hard to predict what will hapend if the backbend are different.

2 Likes

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.