Graphics opacity defaulting to 0 with D2D?

[aaronleese1]

I have a couple components that only draw an image in their paint methods:

void paint (Graphics& g) {

    g.drawImageAt(myImage, 0,0);

}

I eventually realized that once I switched to D2D, these images stopped showing up (they still paint properly on mac, and with windows software rendering).

Apparently, the filltype being used by the components Graphics has an opacity of 0.

Calling setOpacity or setColour in the paint routine fixes it, of course.

It seems opacity it should be defaulting to 1 though, I would think, but maybe I am missing something?

[reuk]

So far I haven’t been able to reproduce this behaviour.

• Which JUCE version are you testing? Do you see the same behaviour on the develop branch?
• Can you modify one of the JUCE example programs or template projects to demonstrate the problem?
• Are you painting into a Graphics context created by the framework, or do you only see the problem when painting into a temporary Graphics context that you’ve created yourself?

Reading and debugging through the code, I can’t currently see how the graphics context opacity could be getting set to 0 before calling paint(). It looks to me like a default-constructed Graphics instance should have a fill colour that is opaque black, and this fill should be restored after each paint call by ScopedSavedState guards.

There’s a chance I’m missing something - the quickest way to proceed would be if you could provide a minimal program that demonstrates the problem.

[aaronleese1]

I’m on the latest release build, but it appears to be happening on the latest develop build too.

If I do this in the paint routine for instance:

void paint (Graphics& g) {

    
    g.drawLine(0, 0, 100, 100);

    g.setColour(Colours::green);
    g.drawLine(10, 0, 110, 100);

}

Then only the second line shows up.

I guess I would expect the first line to be opaque black? But instead its transparent.

I don’t think I can just make it happen on the Juce projects. I have a dozen places here where this isn’t a problem, I’ve been trying to figure out if there is something different about the 3 components where it does happen, but have so far come up short.

One of the components repaints on a timer, one uses vBlank. I’ve tried setting the images (a class member) to software type instead of Native, and RGB instead of ARGB, but there was no change. I also tried creating a small image in the paint routine and displaying that, but had the same issue.

That’s when I finally figured out that it was the paint opacity, not the image, that was the problem.

I will say, I have only seen it happen on secondary windows though, not the main document window.

[reuk]

@aaronleese1

I’ve been trying to figure out if there is something different about the 3 components where it does happen

I think there must be something unusual about these components, or the context in which they are painting. Please could you try sticking a breakpoint in one of the faulty paint functions, and send me the full call stack at the point where the breakpoint is hit? Maybe there’s something special about the way that the graphics context is being initialised in the faulty cases.

[aaronleese1]

Sure. There might be a better way to get this out of VS, but here is a screenshot.