Assertion in juce_Direct2DGraphicsContext_windows.cpp

Direct2D
1

I am hitting this assertion randomly (but consistantly when it hits) with JUCE 8.0.0, line 116 of juce_Direct2DGraphicsContext_windows.cpp:

        jassert (layerParameters.opacity != 1.0f
                 || layerParameters.opacityBrush
                 || ! isGeometryAxisAlignedRectangle);
2

Same here, I just switched my project to 8 from 7 and this hit me.

Did you figure it out @fuo?

3

I was not able to isolate and reproduce it consistently enough to be able to track it down.

4
1 Like
5

It’s very easy to reproduce:

Create a juce::Path
Add a float rectangle to it
Set this path as your graphics context clip region.

This will trigger this assertion immediately.

1 Like
6

I did not realize this was the same issue, sorry for the confusion.

7

+1 we’re also hitting this jassert frequently after updating to JUCE8.
Interestingly the layerParameters struct contains bogus information (for example the bounds are set to values +/- 1e38 so something doesn’t seem quite right in the D2D implementation.

Also the components drawn (which are not opaque, and a child component of a component that has ‘setBufferedtoImage(true)’ are not drawn correctly. Removing the image buffering from the parent resolves the drawing issue but doesn’t resolve triggering the assert.

8

Quick update: seems we got hit with the D2D assert:

as well as this issue related to buffered images:

I can confirm that with the latest fixes on develop, the issues around not erasing background for non-opaque Components on another Component that as image buffering enabled have gone, but the assert issue still remains…

9

I’m unsure what you were testing, but the assertion remains.

I’m a bit surprised it’s still an issue. It’s purely a performance improvement opportunity and should NOT be customer (us) facing.

Using a rectangular clip-path is completely acceptable and should never trigger any assertions. It’s fully functional, but could be achieved with a faster D2D method. That’s all that assertion does. It tells the JUCE developers (so not us) that it could be faster if it used another method to create the clip. Instead of a path, it could use a rectangle. Since the path represents a rectangle, the driver detects that and outputs a warning.

Now the JUCE team put an assertion in to test for this case, but instead of only triggering it when they want to know (JUCE_DIRECT2D_METRICS) they trigger it always, which makes it impossible to run a debug version of our products.

If the graphics context had a simple reduceClipRegion ( juce::Rectangle<float> ) method, this could all be avoided, but as it stands the only way to get a float-rectangle as a clipRegion is to create a path, add the rectangle, and use the reduceClipRegion ( juce::Path ) version.

10

Tested it again - and yes it does indeed still show up. Not sure why it didn’t previously. I’ve updated my earlier post… At least the issue around image drawing for buffered parents is gone.

11

Just wanted to note this is still a blocker for me too. It’s triggering on an svg drawable drawAt when opacity is set to 1.0.

12

Thanks for your patience, all. We’ve removed the assertion on the develop branch:

On balance, the assertion was most useful for JUCE maintainers, and we can reinstate similar functionality by switching the D2D debug layer into “information” mode.

2 Likes
13

Could we get a reduceClipRegion ( juce::Rectangle<float> ) to get better performance and better readability of our code? Then we don’t need to create a path object, add a rect to it, etc. and you can avoid the checks.

1 Like