When you define
JUCE_DIRECT2D=1, the GC implementation file apparently needed a bit of TLC… Might be worthwhile chucking this macro into your CI environments, assuming it’s still supported officially.
juce_win32_Direct2DGraphicsContext.cpp (26.3 KB)
Thanks for the update, but the Direct2D backend has never been supported officially…
Ah, that explains it… Any idea how come?
There are a few missing bits and pieces, and it’s all largely untested. Drop shadows will look weird and if you fire up the DemoRunner you’ll see some other places that don’t render correctly.
Sorry, my question was specific to the support itself - I see the merit in using D2D as the underlying renderer, so I was wondering why support for it wasn’t followed through to an official capacity.
Well there’s still quite a lot of work to do (even though it may appear almost done), and other things have taken priority. It’s not received much attention lately as we’ve been experimenting with other rendering backends that would replace it.
Also on Windows?
At what stage of completion are those experiments (ok for not giving dates, but a percentage)?
This is going to derail the post, but I’m extremely intrigued - is the intent to change the design of the low level graphics rendering? Obviously this would affect how
Component and text are rendered, but I think an overhaul is due at this point… For example, I’d love to see
EdgeTable disappear when rendering on the GPU.
More importantly, I’d love to just have better control over the frame buffer and not draw to a texture; being able to just switch shaders (to whatever pipeline that is set; GL, Vulkan, D3D) and apply anything I want to the frame buffer via the
Graphics object would be amazing.