Juce 8 and Direct2D

General JUCE discussion
1

It looks like Direct2D is now mandatory and can not be turned of in favor of the software renderer. This is unfortunate, because we have issues with its implementation and can not use it at this point time. We do have an urgent need to use the new WebView though and it looks like that is not an possibility.

We ran into the limit for bitmap sizes in Direct2D. Is there a word about a solution ?

2 Likes
2

Until a fix lands, you can check out the Direct2D feature overview, specifically “Toggling between renderers.”

2 Likes
3

If you load an Image using the ImageFileFormat, you don’t have the option to specify the image type.

Setting the renderer to the software renderer does not solve this problem as the ImageFileFormat loading seems to be hardwired to the Direct2D image format.

1 Like
4

We are investigating the Direct2D image size limit issue but it’s not a trivial fix. I was hoping changing the renderer would work in your use case for now. I’ll report back to the team.

5

I believe we’re running into a similar (showstopper) issue as well with horrible performance on Windows since switching to JUCE 8.

Switching to the software renderer does not seem to be solving the issues when dealing with ImageFileFormat or other use cases of images created from memory or disk.

In general I have to say that it’s an extremely painful breaking change and having a common type like Image be intertwined so heavily with a specific renderer (by default!) seems wrong to me.

I think that instead - the Direct2D uses of Image should be explicit and not implicit.

I’m now waiting on a new Windows machine that would hopefully help me debug and profile this issue more clearly, currently we’ve just had all test machines show a severe performance regression.

2 Likes
6

Before you do that, how about adding parameters, where Images are created so, that the SoftwareImageType can be used also when loading from a file. Then we can at least continue using the SoftwareRenderer until the image size issue is resolved.

7

I would like that as well. We often want to pre-process the bitmap data before using it, so having the option to load into a SoftwareImage, then massage the data, and as the last step convert to a NativeImage would be perfect. Saves unnecessary copies and conversions.

6 Likes
9

And it would open up the possibility to chop up bitmaps that are too large for Direct2D before sending them to the GPU

10

I can confirm every single word!
Even switching images to the software renderer, the performance is many times slower than Juce7.

11

Bump! I desperately need some fix for this too

12

Thanks for your patience. There’s now a fix available on the develop branch:

2 Likes
13

The change on Dev branch fixes the large image issue for us, and image components in general seem to work much better with the latest dev changes.

We’ve noticed however that when moving a window around the desktop with lots of image components (and repaints due to metering, think ‘large virtual mixer’), the whole GUI flashes, like it fails to repaint the whole GUI on some of the vblanks.

Is this an issue the team is aware of? Obviously this was only seen with the dev branch (we cannot load this GUI with JUCE 8 release), but it would need fixing before we can move to JUCE 8.

14

Thanks for reporting. I’ve pushed a change to the develop branch that should fix this issue:

Please try updating and let us know if you still see problems.