Juce 8: Decline in Windows font rendering quality

@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.

1 Like

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.

2 Likes

If anyone on the JUCE team is still monitoring, this is still happening to me on JUCE 9. It seems inconsistent, though. The fonts look absolutely awful on my machine but every tester that I’ve asked (only a handful) says that they look fine (taking that with a grain of salt though given that I trust my eyes more than theirs). I have no idea what might be strange about my computer but happy to share specs/info.

The good news is that the software renderer seems much improved for JUCE 9, and the fonts look great over there, so I’m transitioning over to that. It’s just a little nerve-wracking to make a pretty big change like that.

I’d be happy to give the JUCE team any specs and font files that seem to be causing issues. I haven’t really tested with many other font files so I don’t know if any in particular work/don’t, but it seems to be an issue on my machine regardless of format (TTF vs. OTF) or hinting/stripped hinting.

Can you share some screenshots comparing the bad rendering to the software renderer’s output? You can email them or direct message us if necessary. Also, have you tested how other applications (notepad, web browsers) render the same text when using the same foreground/background colours? Does the JUCE rendering differ from the rendering in other applications?

What sort of display are you using on your machine? Is it a high-resolution display, and is it rotated from the ‘default’ orientation?

Huh, this is actually very interesting. I went to take some screenshots, and beamed them over to my Mac to make this comment and upload, and the screenshots themselves look very different than they appear on my Windows machine’s screen. If I open the actual screenshot on Windows, it looks a bit better than it does when actually running the app, but not exactly like it “should”, IMO.

Here’s the bad version (using default renderer):

Here’s the good (software renderer):

(I’m only using standalone out of laziness - it renders the same whether it’s in standalone or in DAW). The easiest thing to do is probably to download them and flip between them, since it’s subtle. The biggest change I see is with smaller text, though it’s all subtly different. In the “bad” version I see that text is slightly thicker whereas the “good” version is thinner. It looks like maybe one is doing some sort of interpolation or massaging for readability while the other isn’t. And, again, it looks quite different on my actual machine - very aliased and choppy.

I’m using the built-in display on my Lenovo ThinkPad on Windows 11. I’m using the default system UI scale of 125% though this manifests with 100% as well. Happy to try to find out what the guts of the machine are. Almost every other app renders text fine - ironically one of the only ones that looks bad to me is the system settings app.

Sorry, did you get the screenshots the right way round? For me, the one labelled ‘bad’ has the thicker-looking text, and ‘good’ has thinner text.

There are differences elsewhere, too. The thin lines in the logo in the bottom right look a bit different between the two renderers.

I’m not sure how helpful the following information will be, but here’s some observations I’ve had with fonts in plugin development (in JUCE and elsewhere):

  • I’ve been using the Visage library a lot lately, and it also sometimes renders fonts poorly on Windows. So this isn’t just a JUCE thing.
  • Font details between software can vary a lot (I remember working on a Kontakt library, and the standard Kontakt fonts looked very different in Photoshop than they did in Kontakt - even with the exact same settings - and it drove the designer nuts).
  • Sometimes I have to change sizes or weightings to get a closer stylistic match (Figma renders thin/narrow fonts much more clearly than JUCE or Visage, so I often have to swap ‘thin’ options for ‘regular’).
  • Back when you used to be able to own Photoshop, I remember using the different anti-aliasing settings would have a huge impact on quality and readability. And different fonts would look better with different settings, so there was never one universal “good” setting.
  • In JUCE 8 I recall some fonts looking better with an even font size, and some with an odd font size (I assume due to some rounding maths, but that’s just a guess).

TL;DR: Fonts will just always look different in different environments and its something I find you just need to deal with as a UI developer. I’m afraid it’s just kind of part of the job and not always a ‘bug’, though it is annoying

1 Like

Sorry, yes. I labeled them correctly but wrote my comment wrong. Edited.

The logo is a separate change. I started manually resampling and stepping it down with the software renderer because it doesn’t do deep resizes very well.

You gave me the thought to try nudging fonts to make sure they don’t end up with some wonky intermediate value. I found that with a system UI scale of 125%, my plug-in starts running at a complex UI scale like 1.5625.

So I tried taking this into account and nudging font sizes around to compensate (e.g., instead of using 20pt, use 19.84pt which becomes an even 31pt with the scale). However, this doesn’t seem to help. I don’t think it’s as simple as just bumping sizes around, unfortunately.

It seems like, on certain machines at least, there is something genuinely strange with the D2D version, unless I’m doing something tremendously wrong.

I don’t have much to add beyond my original post, but I will say that I have gone as far as switching fonts when going from design to implementation in order to deal with differences in rendering.

Or sometimes you pick your battles and look at the big picture (if your testers don’t see a problem, it’s probably not worth torturing yourself over).

yeah, very fair. The screenshots being normal-ish at least gives me some confidence that something about my particular machine/config/display is strange, and on top of that it seems to be rare. It just drives me nuts and sends me down a rabbit hole every time I have to test something specifically for Windows - I’m sure you know the feel :slight_smile:

1 Like