Text appears blurry on Desktop (Windows)

[AgentOak]

Description

Compared to other applications and Element Web in Firefox, text appears blurry in Element Desktop.

Steps to reproduce

• Open Element
• Observe any text

Example screenshot taken with system font Arial, 14pt in a random matrix room:

(open in new tab so it is unscaled)

All fonts in the UI are affected, not just chat messages. I don't have any other applications where I have seen this problem before. In other applications and Firefox, fonts look very sharp by comparison. This is the same text screenshotted from Element Web in Firefox 82:

Through older issues I've found https://github.com/electron/electron/blob/master/docs/faq.md#the-font-looks-blurry-what-is-this-and-what-can-i-do and it very much looks like that problem, but as I understand this is supposed to be fixed already?

Logs being sent: no

Version information

• Platform: Desktop
• OS: Windows 10 2004 x64
• Version: 1.7.12

[jryans]

Hmm, that is quite curious... We have already applied the recommended fix in that Electron FAQ entry, yes. I'll try to get some feedback from other Windows users to see if this affects them as well.

[resynth1943]

Can you try reproducing this on another Electron app, e.g. Atom, VSCodium, etc.?

[AgentOak]

VSCodium (1.50.1 w/ Electron 9.2.1 based on Chrome 83.0.4103.122) looks sharp: Used the same font - Arial - again, but I had to set 13pt to get the same size.

Zooming into the text shows that Element Desktop renders fonts very differently (I don't know much about fonts myself).

Element Web in Firefox:

Element Desktop: This shows why the font appears so blurry: Look at the word "spell" in the first and second line; the "l"s are rendered differently each time. The "i"s in the last line are also a good example.

VSCodium:

[jryans]

Hmm, this is quite a perplexing one... Other people in the community have said they are not affected by this on Windows, so it suggests to me that something system specific is happening here...

@AgentOak Are you perhaps pinning Element to a specific GPU, or have you made any other "customisation" to the app like that, which might explain the difference between Element vs. your other apps?

[AgentOak]

Other people in the community have said they are not affected by this on Windows, so it suggests to me that something system specific is happening here...

I have seen one such image posted in #element-web:matrix.org where the poster said they weren't affected, but zooming in to the text shows that it's using the same grayscale rendering as in my screen It's just not as noticeable with fonts this large/on HiDPI.

@AgentOak Are you perhaps pinning Element to a specific GPU, or have you made any other "customisation" to the app like that, which might explain the difference between Element vs. your other apps?

The system I'm on only has one GPU, a Geforce GTX 670 with recent Nvidia Drivers 456.71. The GPU doesn't seem to affect anything anyway; launching Element with --disable-gpu changes nothing about the font rendering. It's a plain installation from the official installer and the blurry font was already there when I started Element for the first time.

[AgentOak]

FWIW, I was able to reproduce it with a fresh installation on another Windows 10 PC (with a Geforce GTX1080 on 457.09), but both PCs were set up by me so they pretty much use the same settings and software.

For completeness, this is the default font on default size (15pt).

[ara4n]

I wonder if the problem here is that the fix we use to make the fonts look crisp at retina on macOS (i.e. to use pure greyscale antialiasing rather than colour-fringing subpixel antialiasing) is now having the opposite effect on Windows (despite us thinking otherwise at https://github.com/vector-im/element-web/issues/11425#issuecomment-555486636:

    // needed to match the designs correctly on macOS
    // see https://github.com/vector-im/element-web/issues/11425
    -webkit-font-smoothing: antialiased;
    -moz-osx-font-smoothing: grayscale;

@AgentOak can you try opening the network inspector in Electron and hunting down the -webkit-font-smoothing property on the body tag and toggling it on & off to see if that fixes it?

[AgentOak]

DevTools show that the -moz-osx-font-smoothing property is not used at all. For -webkit-font-smoothing, the values antialiased, subpixel-antialiased, none and disabling the property all look the same.

[thany]

I don't think you're going to need any -moz prefixed properties in Electron. Unless you're planning to switch to XUL for the app 🤷‍♂️

For me the difference is also quite noticable, as I can switch the app between my 4K primary monitor and "regular" secondary monitor. The app looks crisp in 4K (where blurry antialiasing is "hidden" by pixels that are too tiny to see anyway), but more blurry than it ought to on my secondary monitor. And since I'm on Windows 10 20H2, I really doubt any OSX-specific properties are going to fix anything.

Shouldn't text just render crisp without any of those properties? Same as Chrome, essentially. The default should be good, as most websites don't use those tacky platform-specific properties, and they all render absolutely fine on all three platforms.

[AgentOak]

That's what I thought as well. Element continues to be the only application I use suffering from this poor font rendering.

The Electron wiki mentions some other causes for this issue (besides the opaque window background) like transforms or subpixel positioning, but for lack of experience with Chromium/Electron I'm not able to diagnose this issue on my own.

[jryans]

I'm making some progress here... I can reproduce the issue in Element and the Electron Fiddle does not exhibit the problem, so it's definitely something specific to what we are doing.

It's not the font smoothing settings either. I'll need to dig a few steps further, but hoping to have a cause isolated soon. 😄

[jryans]

Current Status

From my perspective, this is effectively a Chromium rendering choice / regression, and you can find many bugs across the Chromium bug tracker around different variants of this issue over the last few years, such as https://bugs.chromium.org/p/chromium/issues/detail?id=1016062.

It appears we can apply various CSS workarounds to regain ClearType's subpixel antialiasing, by adding things like:

• contain: paint
• background: some-opaque-color
• transform: translate3d(0px, 0px, 0px) to force a compositing layer

However, it feels like a nasty hack to me, as it may force other browsers to use less optimal paths purely to solve a Chromium-specific issue. There's nothing specific to Electron here, as the same issue is observable in Chrome as well.

Other Apps

Looking at how other similar apps perform in Chrome on Windows:

App	Antialiasing
Element	grayscale
Hydrogen	grayscale
Slack	grayscale
Discord	subpixel

Next Steps

Rather than applying the hacks above, it would be better to work out precisely which things are causing Chromium to fall back to grayscale in our case. This will likely require some painful CSS bisection. 😖

[thany]

Slack definitely doesn't look nowhere near as blurry as Element does, even though it does indeed appear to render with greyscale antialiasing... So there might be something else at play than just subpixel vs greyscale.

[thany]

I'm curious to know if there's any progress being made. I thought the fix could be copypasted from any other opensource electron-based application.

There are two issues at play:

1. Greyscale rendering instead of subpixel rendering
2. Blurrier rendering regardless of (1).

The second issue is solved in a number of other electron-based applications, among which are Slack and VScode. Having their fix in Element as well, may solve the problem. They too have greyscale rendering rather than subpixel. But they do render sharp text regardless.

As for greyscale rendering vs subpixel, that's an additional improvement that could further improve clarity.

[jryans]

No further progress has been made. I'm sure this issue will be updated when it happens.

[thany]

Sad to hear it. Anything I can do to help?

[madig]

Isn't the actual issue that the Inter font used by Element does not have hinting? Same for the Inconsolata font for code, etc. No amount of messing with rendering settings is going to fix that, you need to either (auto)hint the fonts or use different ones.

[AgentOak]

@madig I tested with the Arial system font (which can be set in Element settings -> Appearance -> Show advanced) in the screenshots above. It's better than the default font which is completely unbearable to me, but still blurry.

[Palid]

Trying to figure out how VSCode team solved this problem, as I remember even last year that VSCode was super blurry on my windows machine for some reason, but I didn't investigate.

[Palid]

It seems that in Discord in Chrome the sub-pixel rendering is not turned on for every layer. It's not working for rooms, your chats, etc, but works for the general chat. Generally the rendering is very inconsistent even though it looks good. Probably this issue should consist of two separate things: 1: Figuring out how to improve fonts legibility on Windows 2: Turning on subpixel rendering in Chrome/Electron for at least the Timeline/Chat window

[Palid]

Found the culprit: It's this line of css: backdrop-filter: blur

seems that for some, still unknown to me reason, chrome decides to make a layer that's of a size of the entire window, even if you constraint it. If you want to use backdrop-layer: blur you need to use it extremely sparingly and surgically, otherwise it thrashes the Chrome's layers and breaks font rendering. This surgical precision may still not be enough, though. Currently looking for a solution that won't screw up our designs.

[thany]

I wonder if it shouldn't be using ::backdrop instead, since backdrop-filter appears to be useful for elements (dialogs I suppose, like the settings?) that show the background through, which Element doesn't do.

[Palid]

Pull request solving this problem (in progress): https://github.com/matrix-org/matrix-react-sdk/pull/6262

[Palid]

Related, as it should reduce layout trashing and remove the case where we have couple of frames of improper font (grayscale) when loading new messages https://github.com/matrix-org/matrix-react-sdk/pull/6054

[Palid]

Just so it won't get lost, the VSCode team fought with the same problem and found a solution, that unfortunately doesn't look like it works for us: https://bugs.chromium.org/p/chromium/issues/detail?id=1016062#c22 If someone could figure out how to use their solution for our problem, that would be actually pretty awesome!

[Palid]

@AgentOak @thany @madig can you check now if it's better? There's still some grayscale fonts antialiasing on the left column, but the entire timeline should have proper antialiasing now.

[Palid]

Just to write a post-mortem of this issue: there was a few things breaking the fonts rendering.

• Invalid DOM tree - our left panel wasn't separated from the timeline in the a clear way, which made Chrome treat everything that happened on that tree on the same layer as the timeline (it was a direct sibling instead of it's container being a sibling to timeline container)
• CSS transforms not behaving nicely with the above; instead of being able to clearly separate layers we had those merged together in the rendering pipeline
• backdrop-blur should still not be used, it's a very buggy and problematic property that additionally enforces lots of new layers, even if you try containing it

Generally, we had too many layers that weren't properly contained. We now have a bit less layers with proper containers, which additionally makes the rendering a tiny bit faster too (barely noticable on fast build, very noticable on slower machines, on Firefox in Windows VM it was 2-3x difference in terms of rendering speed for things like resizing the left panel).

[AgentOak]

Thank you, font rendering has subpixel-AA in the main chat window now. Very nice!

The contact/room names in the sidebar are still grayscale as you said, and all in-window overlays like the settings are completely grayscale as well.

[Palid]

Sounds good! I'm closing this issue, if the contact room/left bar is going to be unreadable then let's make another issue for that, as it's going to be another round of unrelated bugfixes. For now I think we're good though!

[thany]

The issue may be closed, but the problem is not fixed. Is this going to be released soon or have you been fixing something else?

[SimonBrandner]

@thany, do you still see this on 1.8.2? It should be fixed there

[Palid]

The issue may be closed, but the problem is not fixed. Is this going to be released soon or have you been fixing something else?

Do you still see the problem in Timeline view? If yes, please hit me up on Matrix, @palid:matrix.org and we'll see what else can we do.

[thany]

@thany, do you still see this on 1.8.2? It should be fixed there

Yep, I'm on 1.8.2 and text is still blurry.

Do you still see the problem in Timeline view? If yes, please hit me up on Matrix, @Palid:matrix.org and we'll see what else can we do.

I don't know what Timeline view is, but ALL text is blurry.

[Palid]

@thany can you give me some screenshots, or ping me directly on matrix as I asked above, so we can figure this out? I don't have enough data to clearly reproduce your problem. The timeline view is basically the main chat window, btw.

[Jieiku]

For me the issue is not element-web vs element-desktop. It is apparently element-desktop vs element-web in FIREFOX! Also the size of the image plays a roll in how blurry it will appear.

Here is an image I pasted to chat in element-desktop:

Here is the result with both Firefox and element-desktop showing, Firefox is on the left, notice how much sharper it is.

[novocaine]

From https://github.com/vector-im/element-web/issues/22267

If I explicitly disable FXAA and launch the application again, it seems to have disappeared.

Which does seem to reinforce that an option to disable hardware acceleration on windows would be useful.

[thany]

This is blurry:

This is correct:

What I did: I went into the developer console, and changed the body font to sans-serif. That's all.

What it means: Element's font is not properly hinted. This is not easy to do, but it has to be done. So please implement a default system font at your earliest convenience (i.e. the next update). Or get your fonts properly hinted, ladies and gentlemen. On your 4K screens this is just not as much an issue, but I don't have 4K or HDPI everywhere.

Additional notes:

1. In the console I saw a huge list of fonts it might choose from, including specialised emoji fonts.
2. Some of those are system fonts of a system that this isn't (Apple fonts, but I'm on Windows). If you have to make different builds for each OS anyway, you might as well make your font list platform dependent.
3. Every piece of text in the whole app still seems to render correctly with sans-serif, including emoji, and letter shapes look pretty much identical. Not nearly unique enough to warrant a custom font, iyam.
4. Most importantly: a custom font is NOT important if it reduces legibility. Or rather, a custom font is not important, full stop.

[t3chguy]

You can change fonts in Settings > Appearance > Advanced.

[thany]

This should not be a preference. Or at least there should be a good default, not a blurry one.

After all, this problem will exist for everyone. As long as they run Element on Windows, on an LDPI monitor.

[t3chguy]

Given this issue has only a single upvote, it does not seem that many people are encountering a blurry font for whatever reason.

[thany]

Or they aren't noticing it, or they aren't reporting it.

And also, this preference doesn't excuse you from properly hinting your custom fonts. Because they aren't. That's clear as day, isn't it??

[t3chguy]

Related https://github.com/philipbelesky/inter-ui/blob/main/README.md#hinted-vs-unhinted

[novocaine]

@thany do you see hinting issues on Element Desktop only, or also on Element Web? Any difference between different browsers?

[thany]

@novocaine Let's try Firefox and Edge.

• On Firefox 100, I'm seeing the same difference as on dekstop. Which is odd, because it's a totally different layout engine.
• On Edge 101, system font looks less blurry than custom, but more blurry than on Firefox. Which is also odd, because desktop and Edge use a similar layout engine.

I'm comparing whatever Element's default custom font is, against sans-serif.

Let me ask you the same question: are you seeing any hinting issues, especially when comparing the two? On Windows desktop, on different browsers?

[novocaine]

Thanks.

I agree with you that Element should use a font that by default renders well on all screens, hardware and settings. There seem to be several factors in play on Windows which means people get differing experiences which prove hard to pin down:

• Layout engine (fixed to Chromium on ED, but we need to solve for web as well)
• Whether hardware acceleration is enabled, and therefore, what hardware you have. (I created a PR to toggle this last week)
• How ClearType is configured on your system
• Whether the font itself has adequate hinting
• The dot pitch of the monitor
• Whether the monitor is driving its native resolution

Let me ask you the same question: are you seeing any hinting issues, especially when comparing the two? On Windows desktop, on different browsers?

I'm using OS X on a HDPI screen.

[novocaine]

https://github.com/philipbelesky/inter-ui/blob/main/README.md#hinted-vs-unhinted

This may be the issue; see also https://rsms.me/inter/#faq-unhinted-vs-hinted

[thany]

Can someone also please answer this: why is it important for Element to use a custom font in the first place? Why would literally any user care for this?

[t3chguy]

It was chosen by product/design, so probably for brand identity & cross-platform consistency, maybe for functional reasons like ligatures. An answer to that question would be better found on https://github.com/vector-im/element-meta

[novocaine]

Can someone also please answer this: why is it important for Element to use a custom font in the first place? Why would literally any user care for this?

here is a draft PR with a hinted version of Inter: https://github.com/matrix-org/matrix-react-sdk/pull/8676

can you try the resultant build here and indicate whether you prefer this rendering on your super awesome lodpi windows rig

[thany]

@novocaine No need to be diminuitive of someone not having all HDPI screens.

The resultant build is slightly better. But it's still no match for a system font. Also, text in the sidebar in the settings panel looks weirdly condensed regardless of font. This is not the case in the current release build.