Direct2D preview branch

Hello all.

We are delighted to announce that a preview of the new Direct2D (Windows) renderer is now available on the direct2d branch of the JUCE GitHub repository:

We would encourage anyone interested in GUI rendering performance on Windows (which is likely a large percentage of our users) to give the new renderer a try so that you are prepared for its introduction in JUCE 8.

Using Direct2D

All you need to do is to pull the JUCE repository and switch to the direct2d branch. Rebuild and run. The Direct2D renderer will be used by default on Windows

If you are interested in better optimizing your painting to work with Direct2D, please refer to this repository:

Here you’ll find PIPs that test the renderer as well as notes on how best to take advantage of Direct2D.

New features since the last preview

  • Direct2D windows can now contain child windows that use GDI or OpenGL to render. That means that legacy plugins that use the software renderer can be hosted inside windows that use Direct2D.

  • Image bitmaps are now cached in the GPU for significantly increased performance; there’s now a full implementation of NativeImageType and ImagePixelData for Direct2D.

  • Path objects are now cached in the GPU using geometry realizations, again for significantly increased performance.

Reporting issues

Please either reply to this thread, create a new topic using the Direct2D category, or submit an issue on @matt’s example repo on GitHub.

The implementation of the Direct2D renderer may change significantly between now and the official integration into JUCE 8. There are some non-standard additions used for profiling that likely will not last through the official merge, and we expect that broader testing will uncover issues that we will need to address.

34 Likes

I don’t know if you’re soliciting reports at this juncture, but in general it works fine. I do note, however, that the path stroking is quite a bit thinner than on macOS, Linux, and with GDI+. Thinner lines show aliasing and stepping and look quite “un-pro,” to the point where I’d have to do an #if WINDOWS situation, which is obviously counter to the entire concept of JUCE.

This is difficult to screenshot, as the Windows screenshot mechanism is different than the macOS one, looks fuzzy. But to recreate:

float myPixel = (float)getWidth() * 0.001f;
g.setColour(Colours::black);
g.fillall();
g.setColour(Colours::red);
[ make a path with some curves in it]
g.strokePath(p, PathStrokeType(myPixel, etc.), etc)

On Windows with the Direct2D branch this will be quite thin and aliased, but on Mac and Linux it looks fine.

Reports are welcome. Thanks for trying i tout.

How do you have your desktop DPI scaling set?

What is the value of myPixel?

Could you please provide the rest of the code in your example?

Alternatively, you could modify this example:

Try disabling caching for the path by calling Path::setCacheEnabled and see how it looks.

Matt

Hello, I’m trying to give this a shot but I’m getting this when building the project with the D2D branch. I’m not sure if it’s related but when I try clicking on the only binary image (png) in the project from within Projucer, it crashes instead of displaying the image. It seems like there’s an issue with zlib.h. Sorry if it’s something silly on my end. Thanks for taking a look.