# Assertion in juce\_Direct2DGraphicsContext\_windows.cpp **URL:** \ **Category:** Direct2D\ **Created:** [June 22, 2024, 9:46pm UTC](https://forum.juce.com/t/assertion-in-juce-direct2dgraphicscontext-windows-cpp/61956 "2024-06-22T21:46:45Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![fuo](https://avatars.discourse-cdn.com/v4/letter/f/ba8739/32.png) [@fuo](https://forum.juce.com/u/fuo)\ **Post date:** [June 22, 2024, 9:46pm UTC](https://forum.juce.com/t/assertion-in-juce-direct2dgraphicscontext-windows-cpp/61956/1 "2024-06-22T21:46:45Z")
I am hitting this assertion randomly (but consistantly when it hits) with JUCE 8.0.0, line 116 of `juce_Direct2DGraphicsContext_windows.cpp`: ```auto jassert (layerParameters.opacity != 1.0f || layerParameters.opacityBrush || ! isGeometryAxisAlignedRectangle); ``` ---
**Author:** ![onar3d](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/onar3d/32/4972_2.png) [@onar3d](https://forum.juce.com/u/onar3d)\ **Post date:** [June 28, 2024, 2:32pm UTC](https://forum.juce.com/t/assertion-in-juce-direct2dgraphicscontext-windows-cpp/61956/2 "2024-06-28T14:32:57Z")
Same here, I just switched my project to 8 from 7 and this hit me. Did you figure it out @fuo? ---
**Author:** ![fuo](https://avatars.discourse-cdn.com/v4/letter/f/ba8739/32.png) [@fuo](https://forum.juce.com/u/fuo)\ **Post date:** [June 28, 2024, 2:54pm UTC](https://forum.juce.com/t/assertion-in-juce-direct2dgraphicscontext-windows-cpp/61956/3 "2024-06-28T14:54:40Z")
I was not able to isolate and reproduce it consistently enough to be able to track it down. ---
**Author:** ![matt](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/matt/32/18340_2.png) [@matt](https://forum.juce.com/u/matt)\ **Post date:** [June 28, 2024, 2:59pm UTC](https://forum.juce.com/t/assertion-in-juce-direct2dgraphicscontext-windows-cpp/61956/4 "2024-06-28T14:59:01Z")
> [@JUCE 8 + D2D assertions](https://forum.juce.com/t/juce-8-d2d-assertions/61624/17): > > I’m not sure what the official decision is here. For now I recommend changing preprocessor directive to #if JUCE\_DEBUG && JUCE\_DIRECT2D\_METRICS Matt ---
**Author:** ![Toddler-Boy](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/toddler-boy/32/2007_2.png) [@Toddler-Boy](https://forum.juce.com/u/Toddler-Boy)\ **Post date:** [June 28, 2024, 4:41pm UTC](https://forum.juce.com/t/assertion-in-juce-direct2dgraphicscontext-windows-cpp/61956/5 "2024-06-28T16:41:08Z")
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. ---
**Author:** ![fuo](https://avatars.discourse-cdn.com/v4/letter/f/ba8739/32.png) [@fuo](https://forum.juce.com/u/fuo)\ **Post date:** [June 28, 2024, 4:59pm UTC](https://forum.juce.com/t/assertion-in-juce-direct2dgraphicscontext-windows-cpp/61956/6 "2024-06-28T16:59:47Z")
I did not realize this was the same issue, sorry for the confusion. ---
**Author:** ![djb-2](https://avatars.discourse-cdn.com/v4/letter/d/73ab20/32.png) [@djb-2](https://forum.juce.com/u/djb-2)\ **Post date:** [July 4, 2024, 8:23am UTC](https://forum.juce.com/t/assertion-in-juce-direct2dgraphicscontext-windows-cpp/61956/7 "2024-07-04T08:23:10Z")
+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. ---
**Author:** ![djb-2](https://avatars.discourse-cdn.com/v4/letter/d/73ab20/32.png) [@djb-2](https://forum.juce.com/u/djb-2)\ **Post date:** [July 4, 2024, 8:39pm UTC](https://forum.juce.com/t/assertion-in-juce-direct2dgraphicscontext-windows-cpp/61956/8 "2024-07-04T20:39:12Z")
Quick update: seems we got hit with the D2D assert: > [@JUCE 8 + D2D assertions](https://forum.juce.com/t/juce-8-d2d-assertions/61624/17): > > I’m not sure what the official decision is here. For now I recommend changing preprocessor directive to #if JUCE\_DEBUG && JUCE\_DIRECT2D\_METRICS Matt as well as this issue related to buffered images: > [@\[Bug\] Issue with setBufferedToImage and Direct2D Rendering in JUCE 8](https://forum.juce.com/t/bug-issue-with-setbufferedtoimage-and-direct2d-rendering-in-juce-8/61821): > > When setBufferedToImage is set to true on a child component, and that component contains its own child components, the Direct2D renderer does not clear the buffered image correctly before repainting. This results in an accumulation of frames where past frames remain visible. Using a custom CachedComponentImage with juce::SoftwareImageType() instead of the default juce::NativeImageType() prevents the issue. However, this causes an assertion failure in juce\_RenderingHelpers.h on line 2203 when us… 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… ---
**Author:** ![Toddler-Boy](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/toddler-boy/32/2007_2.png) [@Toddler-Boy](https://forum.juce.com/u/Toddler-Boy)\ **Post date:** [July 4, 2024, 9:09pm UTC](https://forum.juce.com/t/assertion-in-juce-direct2dgraphicscontext-windows-cpp/61956/9 "2024-07-04T21:09:47Z")
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 )` 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. ---
**Author:** ![djb-2](https://avatars.discourse-cdn.com/v4/letter/d/73ab20/32.png) [@djb-2](https://forum.juce.com/u/djb-2)\ **Post date:** [July 5, 2024, 3:28am UTC](https://forum.juce.com/t/assertion-in-juce-direct2dgraphicscontext-windows-cpp/61956/10 "2024-07-05T03:28:49Z")
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. ---
**Author:** ![sudara](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/sudara/32/8071_2.png) [@sudara](https://forum.juce.com/u/sudara)\ **Post date:** [July 8, 2024, 5:49pm UTC](https://forum.juce.com/t/assertion-in-juce-direct2dgraphicscontext-windows-cpp/61956/11 "2024-07-08T17:49:31Z")
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. ---
**Author:** ![reuk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/reuk/32/21494_2.png) [@reuk](https://forum.juce.com/u/reuk)\ **Post date:** [July 10, 2024, 10:07am UTC](https://forum.juce.com/t/assertion-in-juce-direct2dgraphicscontext-windows-cpp/61956/12 "2024-07-10T10:07:24Z")
Thanks for your patience, all. We’ve removed the assertion on the develop branch: > > > This assertion was intended to emulate a performance warning that could > be emitt…ed by the D2D debug layer, but it often gets in the way during > development. To check for this performance issue, users can change > D2D1\_DEBUG\_LEVEL\_NONE to D2D1\_DEBUG\_LEVEL\_INFORMATION in > juce\_DirectX\_windows.h 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. ---
**Author:** ![Toddler-Boy](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/toddler-boy/32/2007_2.png) [@Toddler-Boy](https://forum.juce.com/u/Toddler-Boy)\ **Post date:** [July 10, 2024, 12:21pm UTC](https://forum.juce.com/t/assertion-in-juce-direct2dgraphicscontext-windows-cpp/61956/13 "2024-07-10T12:21:33Z")
Could we get a `reduceClipRegion ( juce::Rectangle ) ` 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.