I just saw this, and I feel like I have to comment:
About a year ago, we did exactly what you’re doing right now. We made it fully work, with memory-based fonts and everything. First, we were very excited, probably similar to how you feel right now. Only after the majority of the work was finished, the disappointment set in.
The good: it’s about twice as fast as using OpenGL to render the standard JUCE components.
The bad: since JUCE splits all paths (thus almost everything) into separate scan lines and then splits those into sometimes individual rectangles, the rendering was STILL slower than the software renderer (overall, combining both threads).
The OpenGL and Direct2D low-level contexts feed their drawing commands to a background thread executing the actual drawing. If you measure the CPU time spent in your main thread AND the drawing background thread, you will realize that both together still take more CPU than just using the software rasterizer.
Of course, if you do simple tests and draw a giant rectangle and nothing else on the screen, then both the OpenGL and Direct2D contexts will be a lot faster. But as soon as you add some real components, texts, gradients, etc., it all comes crumbling down.
On top of that, the Direct2D gradients use a different gamma correction than OpenGL and the software renderer, and we couldn’t find a way to change/disable it. So your gradients will look notably different.
The text will look slightly different too. If I remember correctly, it looked quite a bit thinner. Maybe the gamma correction again?
Even if you think you can live with all that, both the OpenGL version and the Direct2D version seem to work just fine, but when you open multiple instances of your plugin, then the fight over the resources starts. We had three windows open and suddenly the background thread was overloaded with drawing commands, slowing the whole thing down to a crawl. It was a stutter-fest. All three windows stuttered like crazy. Way worse using the software renderer. Forget about opening a fourth or even fifth window.
This was on an i9-9900K / GTX 1060, build in release mode. Written by a 20+ year veteran from the video games industry.
The way JUCE builds the rendering paths, breaks them into scan lines, etc. is simply not workable for an HW accelerated UI.
Sorry to be the bearer of bad news and good luck.