In what way(s) is JUCE Direct2D currently incomplete?

Is there an official to-do list, or a critique or analysis by the JUCE team? A user wish list?
Or is “incomplete” in fact past tense, and D2D now considered complete by the team?

It’s not complete. It’s been pushed off by the JUCE team for a looooong time now. It got touched up a bit in June or July related to some other code cleanup but other than that as far as we know it’s just in the backlog. Unfortunately despite the hardcore JUCE-ers being a fairly tight knit community they generally don’t share roadmaps with us (probably because things frequently get pushed/pulled in priority based on what ROLI needs).

Personally, the reason I want to see it completed is because JUCE rendering is atrociously slow on Windows due to the software renderer no longer cutting it in the world of animated UIs and high DPI displays.

I’d also be curious to know what’s considered incomplete by the JUCE team, since there are stories out there of people using the D2D backend without issue. I haven’t been able to get it to work under Windows 10, but that was a long time ago and I haven’t tried since. My guess is the issues are related to wide OS support/testing, and/or making workarounds to ensure consistent near-pixel-level behavior with the software renderer (which is something the team is proud of achieving with the GL and CoreGraphics backends).


Yes, good question - TBH I can’t really remember which bits were unfinished (though I bet it involves fonts!) Agreed that we really should bump this up our priority list…


Yes, I sincerely hope you’ll increase the priority. Vector drawing performance would gain from this and I still hope for Windows Store support…

I honestly wouldn’t make any assumptions like that! Wouldn’t be the slightest bit surprised if it turned out slower in some cases.

It might depend on the use case, but in my experience Direct2D is definitely faster. I use Direct2D to draw waveform paths in the Windows version of Acoustica, since we wanted anti-aliased waveforms and drawing JUCE paths wasn’t quick enough for a good UI experience.

1 Like

It’s a +1 for Direct2D from me. Finding OpenGL on Windows a bit underwhelming performance wise. Just discovered that disabling it, and going back to software rendering, made our JUCE test app UI feel significantly quicker! Particularly when resizing a window, which is slow and flickery (happens in the DemoRunner too - select any OpenGL demo, then resize the window). Even resizing an empty window with no child components in a release build is slow.

FWIW, profiling shows that a lot of time is spent in OpenGLContext::CachedImage::renderFrame(). There’s a call to context.makeActive() which indirectly calls wglMakeCurrent(), and that seems to be super expensive (at least on my 2016 Dell XPS13 laptop).

ps. I should point out that I’m evaluating JUCE for a new project, and so far at least, I’m very impressed! The only concern I have at the moment is UI drawing perf. Software rendering is pretty good by Windows app standards, but I was hoping to have silky smooth hardware accelerated UI with minimal CPU overhead. It seems that OpenGL might not be quite up to it - unless I’m doing something wrong.

You’re not doing it wrong, in all cases I’ve seen graphics performance under Windows is very weak compared to macOS.

D2D can be made to work on Win7, but the baseline may or may not have an official fix for a problem I posted on months ago, maybe in late 2017. I posted an experiment, not a fix, I’m just a noob who happens to be ok with D2D, at least for now.

If you wanna read my post, I assume you can search posts by username, I’ve never tried it here.

Also, I got an email from a user named Jellyzone about a month ago, who came up with his own experiment, which they seemed happy with.

I’m not sure that Juce is the best representation of hardware rendering capabilities of any Operating system or API.