@ibisum, I don’t think your ramblings about HWND are particularly helpful here unless you can demonstrate that they contribute to the issue discussed in the thread.
This is not about performance cost, and I don’t think anyone would care too much if a popup menu opens in 10ms or 20ms. This is about rendering quality, and the amount of involved HWND does not factor into the quality of the rendering.
Are any of the involved components cached to a bitmap? Maybe even buy your own code, not by JUCE directly?
These screenshots look like that text was rendered at a lower resolution and then upscaled.
We had to tweak our sizes a tiny bit for Windows, but now, even when comparing screenshots, we can’t tell the difference between our UI being rendered on Mac or Windows. They look virtually identical.
So what you’re experiencing doesn’t seem typical.
Incorrect. Windows has per-process and system-wide limits on the GDI. If you meet these limits, the system might choose to use a simpler rendering method, reducing quality. If resource exhaustion nears, Windows might fallback from Cleartype to grayscale anti-aliasing, it might skip font hinting or subpixel rendering, or it could fail to render at all in worst cases.
JUCE doesn’t use ClearType nor GDI. It also doesn’t create hundreds of HWND.
Juce uses DirectWrite which uses cleartype AFAIK
Clear type is intentionally disabled. JUCE uses the grayscale mode for various reasons.
