Direct2D performance questions

[aaronleese1]

Hey all -

I am developing plugins for a few companies. One of them pointed out that rendering on Windows 11 can become very slow when multiple windows are being rendered.

I was able to see that it is indeed the case. I’ve tested this with Juce 7 and the latest (develop branch) Juce 8. I have also tested with multiple codebases / plugins and also with openGL rendering enabled, or not.

It seems in each case that multiple windows often causes a very severe slowdown. 2 instances of the same plugin will almost always cause a complete freeze, one plugin window with a (non modal) dialog open will sometimes (often) do the same. I even have trouble with some comboboxes / popup menus.

It’s not 100%, I have at least one (secondary) window that seems not to slow things down much at all. No idea why though.

I assume that (maybe) Direct2D is used by windows now whether or not openGL is running (is that true?).

If so … I know that the setPixelAt function as well as some other image based things can greatly slow things down. That is the only potential culprit I can think of so far.

Have others seen something similar?

I will also note that, post win update, everything seems almost unusable on my (fairly new) windows computer. VisualStudio in particular has slowed to a crawl. Not ideal

Not sure if this is relevant:

Rendering multiple instances of a plugin with OpenGL

I have a problem concerning OpenGL rendering performance in JUCE.  Everything works fine as long as I have at most one editor open. When I open multiple instances of the plugin, I can see the performance drop significantly.  Of course this can be expected to a certain point, but I think a lot of time is wasted due to synchronization.  Profiling showed that about 50% of the runtime is spent on getting the MessageManagerLock in the method juce::OpenGLContext::CachedImage::renderFrame() when sho…

[aaronleese1]

Ok - I tried a plugin with a test window I have lying around and it got much faster (just a blank window, basically).

So, this is almost certainly related to Direct2D performance (if I understand correctly).

From this thread, it looks like the quick solution involves hacking juce to use native images:

Direct2D Causes Considerable Performance Drop

Over the past week, I’ve been dealing with the fallout of bumping our JUCE version from 7.0.5 to 8.0.3. I’ve since had two forum posts (here and here) that I started while I was attempting to track down the source of the issues my team was having, but treating problems addressed in those threads has not wholly resolved our issue of multiple plugin instances freezing the DAW. For background, here’s the biggest cases I’ve found where calling into Direct2D is prohibitively slow: As mentioned in …

I’ll plan on implementing that, but I wonder if anyone could give me some guidance on whether or not future Juce releases will improve the direct2D limitations, or if I should expect to need to disable them for a while.

In particular, I use a fair number of Image objects that I render on timers, and then convert to Graphics in the paint method.

This is now a problem because (if I understand):
juce::Graphics(juce::Image myImage)
Will create a CPU side version of the image, which is a very expensive action.

Anyway, I have a lot of vector based UIs that use gradients / images in the paint routines … and it seems as though Direct2D has made that problematic.

Any guidance here would be appreciated.

[matt]

I’ve got some thoughts on this, but I just traveled from ADC back to California and I’m still catching up. I’ll try and put something together over the weekend.

Matt

[aaronleese1]

Please do!! I’ve already read your (quite long) epic history of Direct2D integration thread, but wasn’t sure what the future holds.

Can’t wait to hear it!

Also, I was sorry to miss ADC this year.
Hopefully it was well and I look forward to watching the videos.