gStyle->SetFillColor(0) does special effects

I see a behaviour I can’t explain.

If I set the fill color of the current style to 0, all the filled primitives go white.

TColorWheel cw; cw.Draw(); // draws ok gStyle->SetFillColor(2); cw.Draw(); // still draws ok gStyle->SetFillColor(0); cw.Draw(); // goes all white (except at most a black)

Histograms painted with Draw(“COLZ”) have the same feature (a white frame is the result).

Could you explain me what I am doing?

Thank you :slight_smile:

[ROOT 5.16/00 on Gentoo Linux (amd64), gcc 4.1.2, 1.4.0 ]

Yes I see this effect . I will check.
Why do you need to do gStyle->SetFillColor(0); ?

Hi all,

I’m also experiencing trouble with gStyle. I’m using root 5.17 and I do the following :

root [0] gStyle->SetFillColor(0) root [1] TGraph g root [2] g.GetFillColor() (const Color_t)(1) root [3] gStyle->GetFillColor() (const Color_t)(0)
I’m expecting the fill color of the new TGraph to be 0…
I need this otherwise, when used in a TLegend the backgriound color is black…

Thanks !

You should set directly the object attributes not the global ones. That’s not a good pratice to set them in a global way because if you change the object position in the macro its attributes will change also. So you should do:


Setting the attributes in a global way was valid in PAW which was not OO. ROOT is Object Oriented …

My concern is with TLegend and canvas title backgrounds too.

In my program, I load a style and then I wouldn’t care of styling anymore, relying on the fact that all newly created objects inherit the current style attributes. This also allows sharing the same style among different users in an easy way.
TLegend and all TPave’s take the style background color as default, and since I need it white, I chose it to be 0, whence the problem.
It works correctly with the color 10, though, which is my current workaround, so I guess the behaviour is specific to the “0” value, which maybe has a special meaning I don’t know of.

There is nothing wrong about using a TStyle. However note that gStyle->SetFillColor(0) has a special meaning. See documentation of TAttFill at:
Look at “Special case forcing black&white output”


I missed that line, sorry.
It explains what I see.

I guess that my “workaround” of using color 10 instead of kWhite will become the standard (note however that the behaviour of “gStyle->SetFillColor(kWhite)” is not that evident).

Thank you very much for your support.


I have exactly the same concerns as Hamlet. And as I work with several TGraph it would ve quite inconvenient to have explicitely to tell each new instance to update to the current style.

I’ve tried to use the color 10 as suggested… but I have the same behaviour :

root [0] gStyle->SetFillColor(10) root [1] TGraph g root [2] g.GetFillColor() (const Color_t)(1)
And the corresponding legend entries have a black background, making them almost unreadable.
Is it intrinsic to TGraph class ? or am I missing something ?