Have you been able to set this? Could you share how? I don’t understand how these settings can actually be modified. I would be most interested in DWRITE_RENDERING_MODE_NATURAL which is described to disable vertical hinting and use subpixel glyph offsets horizontally if cleartype is enabled. (DWRITE_RENDERING_MODE (dwrite.h) - Win32 apps | Microsoft Learn)
Now that I’ve seen the D2D rendering speeds myself, I don’t consider using the software renderer a valid workaround anymore.
Yes, see some post above, one line needs to be changed in JUCE 8:
I understood the suggested workaround to remove the hinting from your desired font. Not at runtime, but for you to use the tools you’ve mentioned yourself. You have what you need to achieve the result you want.
I defined a type derived from ComBaseClassHelper<IDWriteRenderingParams> and overrode all the virtual functions, then passed a pointer to an instance of this type to deviceContext->SetTextRenderingParams() inside the D2D renderer drawGlyphs().
It sounded like you considered stripping the hinting information to be a viable workaround.
Thanks and oh sorry… yes, I consider the stripping an ok workaround for me, but it won’t work on system typefaces. For general ease of use, it would be great if there was a way to configure this stuff (and cleartype) from JUCE without having to edit fonts.
I found this, tried for about 2h to get it to work and now finally gave up:
It almost does what I want, but is broken on some (thin) fonts… sigh.
Instead of the subclass it is btw. possible to create the com object using IDWriteFactory::CreateRenderingParams and its variants in dwrite_3.h.
Anyway, as said stripping the hinting info from my custom fonts and enabling ClearType gets me where I want and I’ll stop nagging about it now. Thanks everyone.
Thanks!
This looks so much nicer than greyscale on all the examples I tried, even with high DPI.
This should probably be on by default as this is how fonts are meant to be rendered on Windows.
The ideal solution would probably to follow what the user has set in the OS, so he is the one who makes the decision based on its DPI, pixel arrangement, and subjective preferences.
ClearType on Windows doesn’t work well with the pixel arrangement of modern OLED displays. With OLED monitors becoming more common, it’s worth noting that many don’t adhere to the conventional RGB pixel arrangement used in LCDs, with some opting for WRGB or triangular RGB configurations instead. ClearType operates under the assumption that your monitor has a vertical stripe RGB/BGR pixel arrangement, which can lead to rendering issues on OLED displays. Apple removed sub-pixel rendering from macOS starting with version 10.14, so using ClearType anti-aliasing by default on Windows might lead to inconsistent font rendering across platforms.
That is exactly why using the OS settings is the best move there: if the user has an OLED screen then he most probably has ClearType disabled for that screen in the ClearType Text Tuner. If he does not then all his apps will show the same issue anyway.
On that subject, I think the most important thing is to have a rendering similar to the rest of the OS (native apps in particular). Users will never have the same plugin on MacOS and Windows side by side, but they will have other apps to compare to. Why not play by the rules/forte of each system and use the best possible rendering? We are not talking about major differences here, and other differences still exist anyway.
Plus one important thing to consider is that high DPI displays are pretty much the norm on Mac now, making font smoothing less of an issue than with typical Windows systems. Retina is the reason why Apple did not implement ClearType-like solutions (or maybe the other way around…).
Luckily, this is already happening automatically if the D2D1_TEXT_ANTIALIAS_MODE_CLEARTYPE flag is used.
Direct2D pulls the information from the ClearType configuration - and it is happening in real-time.
I ran my Juce app, took a screenshot, then inverted the screen orientation and took another screenshot:
The sub pixel arrangement did adjust to the rotation.
Then I disabled ClearType completely in the OS “Adjust Cleartype” dialog and the d2d rendering also followed this by rendering grayscale:
So it’s all good and no extra logic is needed to fetch the correct information. Direct2D automatically follows the system configuration.
That is not the case on my system (Windows 11).
ClearType stays active regardless of the “ClearType Text Tuner” settings, even if I restart the app. Most other apps (especially native ones) do pick up the change as soon as I click the on/off button on the first page of the tuner.
I’m also using Windows 11. When disabling ClearType I needed to go through all of the ClearType dialogs. I realized that Visual Studio didn’t pick up the change. So I additionally had to restart Visual Studio and launch my app again. Only rotating the display by 180 degrees lead to an immediate change in rendering.
Ok… I tried again today and it seems I was a bit overexcited reporting this .
I had a hard time getting it to render in grayscale again, but then I realized this was caused by the ClearType settings itself.
Note how you still get to choose settings when disabling ClearType in the “Adjust ClearType” app?
Some of these adjust the strength of ClearType and if I choose settings that are grayscale only (using the Magnifier), the app does pick up these settings on next launch and renders grayscale.
However the main ClearType switch is not detected/overridden.
Luckily, the switch should be detectable using SystemParametersInfo(SPI_GETCLEARTYPE, 0, &flag, 0)
I’ll adjust my JUCE patch to look this up and configure the text rendering accordingly.
I listed the wrong constant, SPI_GETCLEARTYPE always returns 1 for me. Maybe it’s just about the availability of cleartype. What does work is using the following in juce_Direct2DResource_windows.cpp around Line 90:
However, it is probably unwise to call SystemParametersInfo on every frame. When I used it in Juce 6, I called it every second. Maybe it is enough to just call it when rendering is initialized - it’s not like people turn ClearType On and Off all the time.
I think not, but I don’t care as I now look it up once only on startup. I read that SystemParametersInfo sometimes can take ‘long’ to complete, so calling it only once seems better.
I agree that it already solves 99% of the situations out there, especially for plugins.
@matt, @reuk any chance we this this integrated as default?
The difference in rendering is pretty dramatic, and mitigates the heavy hinting issue.
I see no downsides as users that do not want cleartype (for compatibility, preference or performance reasons) should have it disabled in their system anyway.