Binary Ninja 3.3 has broken antialiasing with Windows 10 (no HiDPI)

[amyspark]

Version and Platform (required):

• Binary Ninja Version: 3.3.3996 Personal (Build ID e34a955e)
• OS: Windows 10
• OS Version: 21H2
• CPU Architecture x64

Bug Description:

The font antialiasing has been failing for me since at least 3.2. While I could work around it in that version (see below), 3.3 has broken it completely. having blurry widgets even with the default Inter typeface.

Steps To Reproduce:
Please provide all steps required to reproduce the behavior:

1. Go to Settings, type font in the search bar.
2. Set font.app > "Application font name" to "Segoe UI"
3. Restart Binary Ninja.
4. Repeat 1, then set font> "Font Antialiasing Style" to any desired option.

Expected Behavior:
Crisp font rendering.

Screenshots:

With 3.3:

	Inter/Roboto	Segoe UI/Consolas
subpixel
grayscale
none

With 3.2:

	Inter/Roboto	Segoe UI/Consolas
subpixel
grayscale
none

Additional Information:

In 3.2, it was possible to work around this by setting "Segoe UI" and "Consolas" as the application and view font name respectively, plus setting the antialiasing to Subpixel.
In 3.3, this has broken completely and the UI look just wrong irrespective of font and antialiasing option, as shown in the screenshots above.

[fuzyll]

Could you give us some more information about your specific setup? I've tried replicating this on both Windows 10 and Windows 11 VMs, plus a bare-metal Windows 11 install, and I don't think I'm seeing the same font issues that you are.

I tossed Segoe UI in as my font choice and then took two screenshots from inside of my Windows 10 VM:

This is with subpixel antialiasing on.

Now, I'm usually pretty nitpicky about fonts and rendering and stuff, but these seem reasonable to me? They also seem slightly clearer than your own screenshots? But, I dunno, maybe I'm missing something.

[fuzyll]

For completeness, here's how my bare-metal Windows 11 install looks with 3.2:

...and 3.3:

...both with Segoe UI and subpixel antialiasing enabled.

I'm not really of the opinion that any of these screenshots look great. But, for Windows, I think they look reasonable.

I do also think they look a little different than your screenshots, so I'm not suggesting "everything is perfect". I'm just wondering if there might be something else impacting this from your setup, or if possibly VMware is doing something preventing me from replicating the problem with Windows 10 specifically.

[amyspark]

For completeness, here's how my bare-metal Windows 11 install looks with 3.2:

That one already confirms my issue, your 11 VM has no antialiasing:

whereas 3.2 shows the smoothed edges of subpixel Cleartype:

Your 10 VM on the other hand looks OK:

My setup is as follows:

• OS: Windows 10 21H2
• CPU: Ryzen 7 2700x
• GPU: Nvidia Geforce GTX 1660 Ti, driver version 527.56
• Screens: 1080p, 1x Samsung S24F350, 1x LG M2380A, no HiDPI. Both calibrated with ArgyllCMS and with the ICC profile active

I'll check GPU driver settings and ICC profile now and let you know.

[fuzyll]

Thanks, I now understand better what you're talking about. And, actually, I think you might've already helped me understand the problem better. The screenshots I had from Windows 11 are actually not from a virtual machine, which suggests the reason why we didn't catch this before release is that there is a difference between the rendering inside the VM versus bare-metal.

I also have an Nvidia Geforce GTX card in the bare-metal machine I got the Windows 11 screenshots from. I'm wondering if there's an interaction with Qt and device drivers that is causing the issue, since we haven't changed any font rendering code on our end.

[amyspark]

a difference between the rendering inside the VM versus bare-metal

I've not digged into Binja's innards, but are you shipping Qt6? Perhaps it's high DPI antialiasing rearing its head, I believe it's enabled by default there.

[fuzyll]

We are, actually. A quick 1-minute Google search didn't bring up anything in the way of a recent Qt bug regarding high DPI antialiasing. Are you aware of something I could try to resolve the issue?

We do have the following ifdef that shouldn't be compiling into the product now:

#if QT_VERSION < QT_VERSION_CHECK(6, 0, 0)
	QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling);
	QCoreApplication::setAttribute(Qt::AA_UseHighDpiPixmaps);
#endif

...presumably because it is on by default now. I'm not personally very knowledgeable about antialiasing in Qt on Windows, though.

If you're aware of some stuff I could try, please let me know, otherwise I'll try and mess with some settings when I get a chance and see what happens.

[fuzyll]

Does this look better?

I think it does, but I'm obviously not as sensitive, so I want to make sure before I try and figure out how to get this out in a dev build.

[amyspark]

Does this look better?

I think it does, but I'm obviously not as sensitive, so I want to make sure before I try and figure out how to get this out in a dev build.

I think so, yes! I need to test with the system fonts, but the borders look as they should. Let me know if/when I can check it out.

[fuzyll]

This is now live in builds >= 4060 on the dev branch and will be included in the next stable release.

For posterity, there is some problem with Qt 6's default High DPI rendering on Windows. The solution was to put this:

qputenv("QT_ENABLE_HIGHDPI_SCALING", "0");

...before the main QApplication gets instantiated.

Big thanks to Stuart Mentzer's post here that clued me in to this as a possible solution (and pointed out that the solution I tried first probably wasn't going to work). Additional shout out to the Qt 6 documentation that does, in fact, explain how this works...but does so buried at the bottom of the page.