Hey guys,
here we go again with the never-ending story of Mac vs Win fonts rendering. I still can’t figure why custom fonts looks so ugly on windows. Here’s an example
Thanks Ben. I found an error on what I were doing (using Height instead of PointHeight) and fixed the clipping of the top part of my labels, but still the fonts render differently.
I read the thread you posted and found another thread by @matt with is works on D2D implementation. I’ll try his fork and see if the font rendering improves. In the meantime, I made some tests with a 4k monitor on my windows machine. With W10 default 150% scaling, the rendered fonts are blurry; totally pixellated with 200% scaling and nice (still thin) with 100% scaling.
Despite the scale value, Ableton Live 11 GUI was always perfect looking. So the problem looks JUCE related.
Edit: it was just the fonts and disabling “Auto-scale plugin window” does the trick. Thanks @reuk
Fonts are still rendered differently and looks thin on windows, but I guess this is related the post Ben linked earlier.
For what it’s worth, I didn’t see a big difference using DirectWrite + the JUCE software renderer. I did see a significant difference using the Direct2D renderer (which always uses DirectWrite).
JUCE (Windows DirectWrite fonts) vs ‘native’ DirectWrite rendering)
The main difference I notice between JUCE software renderer and native is the sub-pixel anti-aliasing (the colored fringes). You can also see that the center bars of the ‘A’ and ‘E’ are snaped to the pixel grid in native Direct-2D, a trick that increases clarity at the expense of distorting the font a little.
Judging by the uneven ‘brightness’ across words, I would also hazard a guess that JUCE is using screen-color-space antialiasing (sRBG) rather than the more accurate linear color-space anti-aliasing.
So the difference is pretty subtle. JUCE is doing a pretty good job, but native renderers are very sophisticated at wringing that last little bit of clarity out of a font.
I found a workaround: The popup menu window needs to be opaque. Then after addToDesktop creates the peer I need to force the rendering engine again with:
getPeer()->setCurrentRenderingEngine(1);
Now the popup menus show the same nice color-space anti-aliasing.
I recognized that setting the popup menu window opague is enough to have the new renderer working.
I wonder if the technique for text rendering could be used to render svg icons in the same way, so that they could have the same nice color-space anti-aliasing.