Windows 7 was Direct2D 11.0. We’re using DirectX 11.3, which was included with Windows 10.
Windows 7 was given serious consideration, but it only supported a limited feature set for Direct2D. The real challenge turned out to be either finding or building a Windows 7 computer to develop and test against. ISOs are no longer officially available, and Windows 7 has been end-of-life since 2020.
Matt
I’ll also add that all the statistics we have suggest the number of users using Windows 7 is very low, on top of that we need to consider the subsection of those Windows 7 users who are expecting to install new products and updates to existing products. In addition to this we looked at the market including DAWs, plugins, and audio interfaces, and the vast majority have dropped support for Windows 7.
Given the required ongoing effort to continue supporting Windows 7 and all of the above the ROI doesn’t seem worth it.
I finally found the time to build a small example of how SVG rendering differ between VST3 and standalone with the D2D rendered and 200% DPI settings in Windows.
Here is the editor header code that you can easily integrate in a default plugin project:
PluginEditor.h (7.2 KB)
There are two paths: one in obtained from an SVG and the second is a simple ellipse with similar dimensions as the one in the SVG.
When resizing the windows the component will scale and the differences will tend to get more visible.
So here are my findings, with a 200% DPI setting, resizing the window and switching between renderers:
The component also does show the different scale info (display scale, component scale, graphic context scale), and it appears in VST3 mode (at least in reaper, plugin doctor and pluginval) the display scale is always 1 and the component scale does include the display scale.
I think I can reproduce the issue, although the differences are subtle.
It seems that the main difference between the VST3 and Standalone scenario is the arguments to the call deviceContext->SetDpi (...) in Direct2DGraphicsContext::Pimpl::startFrame: in VST3, the arguments will always be 96; in Standalone, the argument will be proportional to the display scale. Keeping the default of 96, or removing the call completely, seems to produce better results in the standalone app.
Please could you try removing the SetDpi call in juce_Direct2DGraphicsContext_windows.cpp and check whether that produces better results for you? Thanks!
Thank you for your quick rely!
Removing the SetDpi call seems to do the trick: it looks better and consistent with other renderers now!
Thanks for trying it out. We need to do a bit more testing to make sure that won’t break anything else, but assuming we don’t find any issues we should be able to get this merged shortly.
You mentioned that you see different scale values reported in plugins vs apps.
This is due to a decision made shortly after the introduction of high-DPI support on Windows (related posts). Ideally, I’d like to spend some time unifying things so that the behaviour is consistent across both plugins and standalones. However, this is likely to be disruptive to existing projects, so it’s unlikely to be addressed in the near future.
Yes, I can’t see how you would solve that without breaking things, unless you add a new API. And even then, components bounds are also affected (eg when taking component screenshots, etc.).
For now I am getting the display DPI that way for plugins on Windows:
juce::Component::getApproximateScaleFactorForComponent( getTopLevelComponent() );
We’ve pushed some significant updates to the Direct2D backend that should improve performance when working with Images. This change will improve performance for projects that use setBufferedToImage, and effects like shadows and glows.
More details here:
We still need some way to disable Direct2D for JUCE 8 plugins running in WINE:
The fix for the SVG rendering differences is now merged:
