Font rendering on LoDPI displays

[rev4324]

Check for existing issues

• Completed

Describe the bug / provide steps to reproduce it

Text rendered in Zed is noticeably more blurry than other editors when using a LoDPI monitor, e.g. an external 1440p monitor like mine, or a (really) old MacBook. I'm well aware that macOS generally sucks at font rendering on non-retina screens, so to make sure my eyes aren't lying to me, I made a little comparison.

I took screenshots of the same code snippet in Zed, VSCode and Xcode and pasted them into Figma, which doesn't apply a bilinear filter when zooming images, so you can zoom in and see the per-pixel difference. Here's the comparison.

To my eyes VSCode is the sharpest, then there's XCode (which is as sharp as every other AppKit/SwiftUI app), then there's Zed with a weird 1px 50% alpha border around the text that made it really blurry. It seems like some sort of AA that doesn't work particularly well on a LoDPI display.

Environment

Zed: v0.123.2 (Zed Preview)
OS: macOS 14.3.1
Memory: 8 GiB
Architecture: aarch64

If applicable, add mockups / screenshots to help explain present your vision of the feature

No response

If applicable, attach your ~/Library/Logs/Zed/Zed.log file to this issue.

If you only need the most recent lines, you can run the zed: open log command palette action to see the last 1000.

No response

[rubnogueira]

I second this. Using Zed with a 1080p LoDPI is very uncomfortable due to the blurriness of the font. This doesn't happen with Sublime, VSCode, or XCode.

[leftbones]

Seconding this as well. Zed looks great on my MacBook screen, but looks bad when I dock to my 1080p monitor. No other editor has that problem for some reason.

[AlexDaniel]

Another side-by-side with the same font (Zed on the left, VS Code on the right):

Open that image at 100% zoom to see the difference.

If that image is too small at 100% zoom on your screen, I'm providing this one which is upscaled 2x.

[leftbones]

Oh wow that 2x side by side makes it very apparent how bad it is. On Jun 18, 2024, at 4:50 PM, Aleks-Daniel Jakimenko-Aleksejev ***@***.***> wrote:  Another side-by-side with the same font (VS Code on the left, Zed on the right): image.png (view on web)<https://github.com/zed-industries/zed/assets/5507503/0c472dea-ec98-4d44-a5f6-ddacc1e182d8> Open that image at 100% zoom to see the difference. If that image is too small at 100% zoom on your screen, I'm providing this one which is upscaled 2x<https://github.com/zed-industries/zed/assets/5507503/9883d388-9728-4fc6-ae3d-10181cf3c3b0>. — Reply to this email directly, view it on GitHub<#7992 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ASMD7PVJ2FOTWW7BUR27QSLZICTTBAVCNFSM6AAAAABDOO5R3WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNZXGEZTQMBRGY>. You are receiving this because you commented.Message ID: ***@***.***>

[ogau]

I also came across a significantly worse font display compared to the vscode editor:

although there are no strong distortions in the enlarged image, visible distortions appear when changing the font size

[JackNWhite]

I want to mention this here (because I mentioned it also on the OTB request), but could this difference in rendering be related to scaling of the fonts? For me, Fira Code at size 15 is much smaller in Zed than in Sublime Text.

[chf0x]

I am having the same issue on a HighDPI screen (Linux). Please let me know if screenshots are needed

[Tiedye]

Same issue as @JackNWhite but in vscode

[jsnjack]

I tried few dark and light themes and the issue is much more noticeable on the light themes

[Rid1FZ]

Same issue here in LoDPI LCD screen(Laptop). I'm using Fedora 40, and installed Zed from the installation script.

[mentalhub]

Is there any quick dirty fix without recompile app from scratch? (tried font weigh more than 500, but still eyecracking)

[leftbones]

Is there any quick dirty fix without recompile app from scratch? (tried font weigh more than 500, but still eyecracking)

I don't think there's any fix, period, unless I missed something? It's a shame, I've been following this issue for quite awhile now and it's really the only thing stopping me from using Zed as my main editor. I spend a lot of time with my laptop docked, and my main monitor is only 1080p so Zed looks like garbage compared to VS Code.

[AlexDaniel]

Is there any quick dirty fix without recompile app from scratch? (tried font weigh more than 500, but still eyecracking)

I don't think there's any fix, period, unless I missed something? It's a shame, I've been following this issue for quite awhile now and it's really the only thing stopping me from using Zed as my main editor. I spend a lot of time with my laptop docked, and my main monitor is only 1080p so Zed looks like garbage compared to VS Code.

I switched to Zed even though the text, indeed, looks like garbage. I hope this gets fixed eventually. 🙏🏼

[pauschuu]

When Zed was officially released for Linux I showed it to some colleagues of mine. Some tried it out and almost all of those made a statement about the bad font rendering on Linux. They use different Linux Distros, some Wayland, some X, so there is no specific "environment" here that seems to be the problem but rather something in Zed itself?

I experimented with all the different aliasing and hinting settings but no success.

There is no way on Linux to get the same font/same size/same weight/same everything as readable as it would be in other applications like VSCode or my terminal, or basically most other applications.

[Rid1FZ]

@pauschuu zed is currently under heavy development. If you look at the release, you'll find that there is a new release almost everyday. The vim mode is not even perfect yet. The plugin system is not great. Currently it only support syntax highlighting for shell scripts. I can make a list of issues. Be patience. Obviously this issue will be fixed soon. But currently there are many major issues on linux like some panics, crashes, etc.

[jliverman]

BUMP

This is by far the worst part about Zed at the moment. Can someone PLEASE look into this?

FYI - I had similar issues trying to get WezTerm to look as good as Alacritty on my Macbook when using an external monitor. It was finally resolved when I changed the "front end" to use WebGpu.

[JackNWhite]

I would like to second this request. I know not everyone is as optically sensitive as some, but for those who are, it makes such a big difference that we cannot seriously consider doing work in Zed until it is fixed.

[rdanilin]

Switched back to SublimeText due to this issue.

[leftbones]

It would be nice if someone working on the project could at least acknowledge that this is a problem, it seems like it's largely being ignored right now. I know they're focusing on macOS right now, but this isn't even a matter of trying to make things work properly on other OSes, I use a Mac but have blurry font rendering because I don't use a high DPI display.

[insilications]

I tried Zed. It looks very promising, but the fonts on Linux with a LoDPI display are looking very bad.

[crisdegraciadev]

Any update on this? I'm thinking about switching from neovim to zed, but this issue is really making me avoid the change.

[gmr458]

Could the solution to this be similar to Neovide's? neovide/neovide#2510

[louis77]

macOS with external LoDPI monitor, fonts (I tried many) are blurry especially on dark themes for me. I have to go all up to 16pt. Doesn't happen with VSCode.

[jansol]

Another side-by-side with the same font (Zed on the left, VS Code on the right):

Open that image at 100% zoom to see the difference.

If that image is too small at 100% zoom on your screen, I'm providing this one which is upscaled 2x.

This particular example looks a lot like vscode is either using an embedded size-specific bitmap version of the font or has antialiasing disabled while zed uses the usual antialiased vector font.

[VorpalBlade]

Another side-by-side with the same font (Zed on the left, VS Code on the right):
Open that image at 100% zoom to see the difference.
If that image is too small at 100% zoom on your screen, I'm providing this one which is upscaled 2x.

This particular example looks a lot like vscode is either using an embedded size-specific bitmap version of the font or has antialiasing disabled while zed uses the usual antialiased vector font.

I'm fairly sure zed doesn't correctly handle embedded bitmaps (Terminus (TTF) has that and it looks unusable in zed). But even fonts that do not use that (Dejavu Mono Sans) don't render the same.

Perhaps zed is ignoring system font hinting and antialising settings that vscode respects? That also seems to be part of it. I use full hinting greyscale AA in my fontconfig settings on Linux and it is pretty obvious that this is getting ignored completely by zed (again making the text unreadable and literally headache inducing for me).

[jansol]

I use full hinting greyscale AA in my fontconfig settings on Linux and it is pretty obvious that this is getting ignored completely by zed

On Linux Zed uses cosmic-text for text rendering, and it does indeed appear that cosmic-text does not use fontconfig (at all!): pop-os/cosmic-text#282

[matagaralph]

Any update on this? I'm thinking about switching from neovim to zed, but this issue is really making me avoid the change.

Same here buddy. Will do switch from VS Code to Zed once font rendering is fixed. It's just painful to read stuff currently.

[mahkoh]

When Zed was officially released for Linux I showed it to some colleagues of mine. Some tried it out and almost all of those made a statement about the bad font rendering on Linux. They use different Linux Distros, some Wayland, some X, so there is no specific "environment" here that seems to be the problem but rather something in Zed itself?

Almost all applications on linux use fontconfig and freetype both of which are very old and mature projects. Due to being old, a lot of work has gone into making them look good on the displays of the time which meant low DPI displays. The primary tool to make text look good on such displays is hinting which means slightly distorting the letters so that they fit the pixel grid.

Unfortunately many people working on fonts nowadays no longer care about fonts looking crisp on low DPI displays. As far as I know, cosmic-text doesn't even support horizontal hinting. Until that changes, no application using cosmic-text will ever look crisp on low DPI displays. Realistically, it won't look crisp unless it supports a freetype backend.

[VorpalBlade]

Unfortunately many people working on fonts nowadays no longer care about fonts looking crisp on low DPI displays.

Low DPI monitors will be around for many more years. Any project that doesn't realise that and handle it somewhat passible is effectively unusable by a significant number of users.

[maxhille]

@mahkoh I am not too much into font rendering as a subject, but just from their respective README.mds:

• Cosmic-text claims to support hinting
• Swash (which is used by Cosmix-text) supports Subpixel-Antialiasing

[mahkoh]

Cosmic-text claims to support hinting

AIUI cosmic uses swash for rendering and swash does not perform the types of hinting supported by fontconfig + freetype. The second have three different levels of hinting that look very different from each other and swash only has a boolean setting.

Swash (which is used by Cosmix-text) supports Subpixel-Antialiasing

Anything subpixel cannot work on a modern system due to scaling and rotation. GTK4 has completely removed subpixel rendering for that reason AIUI.

[mahkoh]

See this blog post RE GTK: https://blog.gtk.org/2024/03/07/on-fractional-scales-fonts-and-hinting/

[VorpalBlade]

See this blog post RE GTK: https://blog.gtk.org/2024/03/07/on-fractional-scales-fonts-and-hinting/

GTK4 font rendering is a horror show by default on low DPI screens. However it is fixable by editing ~/.config/gtk-4.0/settings.ini and adding gtk-hint-font-metrics=true. Without that GTK 4 is just completely unusable.

So that blog post is, quite frankly, full of BS. Yes it works on high DPI screens. Not all of us want to invest in all new laptops and monitors just because of GTK, zed or Cosmic. I'll just not use those pieces of software that can't render text properly.

[zmanuel]

Call me a weirdo, but I prefer non-antialiased fonts even on high DPI displays, at least for text editing where setting it up properly is a battle I can win (using the right font with embedded bitmaps or good hinting). It's not a big difference, I admit. I'll stop caring around 300 DPI, or in five years when my eyes have gotten sufficiently worse :)
Even on low-DPI displays, blurry fonts are not an automatic dealbreaker for me, it's not a hill I'm willing to die on, just one I'll defend while I can.

[rev4324]

On a HiDPI display the pixel density itself makes up for the blurriness you'd have on LoDPI. Actually it's better to disable aggressive font AA on HiDPI, since the font looks more like the artist intended. That's pretty much what macOS does anyway.
Yet on LoDPI I get dizzy from reading all of this blurry text, even if it looks more in line with the artist's intention.

[phoenisx]

In my case, the rendered font weight does not change no matter what Font I set or what font weight I set in the user/system configs.
On Zed the fonts are way too light, with less contrast and harder to read.
I'm using a Samsung 4k display with PopOS

IGNORE: I had the wrong config. The issue got resolved when I changed UI and Buffer font settings

[mahkoh]

A way forward might be https://github.com/googlefonts/fontations which seems to aim for a higher level of compatibility with freetype. The linebender project has switched from swash to skrifa (part of the linked repository) for some tasks. googlefonts/fontations#1215 would be required to reach hinting parity.

[dfrg]

👋 I’m the original developer of swash and I also work on skrifa. For a bit of context, swash now uses skrifa internally for glyph scaling so the two projects can mostly be considered the same when it comes to that functionality.

We’ve agreed to implement the additional hinting mode requested by @mahkoh in the linked issue above but I’d like to note that this is very unlikely to fix the rendering problems presented here.

Fractional positioning, subpixel rendering and gamma correct blending (all on display in the vscode/chromium screenshot above) are all likely to have a much greater effect on rendering quality.

Also, as mentioned, one of the screenshots appears to be a comparison against embedded bitmaps and scalable outlines will never reach that level of crispness on a low DPI display.

[mahkoh]

Please compare the following screenshots of a GTK3 application. In both cases, the font used is DejaVu Sans, the hint setting is hintfull, and antialiasing is set to grayscale. Images have been scaled 10x.

Interpreter version 40:

Interpreter version 35:

I believe the difference in crispness is significant.

If you use the fauntlet application from the google repo, you can see that freetype emits paths whose X coordinates are always integers with interpreter version 35. (You have to hack it a bit because by default it does not initialize this setting from the environment variable.)

Fractional positioning, subpixel rendering

I don't believe these are desirable features. They are not needed on hi-dpi outputs and lead to visible color fringes on low-dpi outputs (seen in the vscode screenshot above). I don't believe they work at all on wayland because application cannot know the subpixel positions, scaling, rotation, etc.

[dfrg]

It is more crisp but the trade off is inconsistent weight and poor inter-glyph spacing. Which is better seems to be a matter of personal preference.

Since the v35 interpreter is unlikely to be enabled by default (it hasn’t been default in FreeType for years, probably because of the visual issues mentioned above), I was simply suggesting well-known techniques to improve quality— a number of the responses here appear to favor vscode’s rendering.

[VorpalBlade]

It is more crisp but the trade off is inconsistent weight and poor inter-glyph spacing. Which is better seems to be a matter of personal preference.

For me is a matter of usability and accessibility. I get literal headaches after a few minutes from the non-crisp rendering.

Since the v35 interpreter is unlikely to be enabled by default (it hasn’t been default in FreeType for years, probably because of the visual issues mentioned above), I was simply suggesting well-known techniques to improve quality— a number of the responses here appear to favor vscode’s rendering.

You can set an environment variable to fix the rendering to use v35. You can also use a TTF with embedded bitmap fonts. Neither of those approaches work in Zed currently.

In vscode I currently use "Terminus (TTF)" as my font, which has bitmap characters at specific font sizes.

[dfrg]

I’m only involved with upstream projects and have no affiliation with Zed so I can’t speak for how our code is integrated. As mentioned, we have agreed to implement support for the v35 interpreter so that will be available.

I’ll also note that swash already provides access to embedded bitmaps but that doesn’t seem to be enabled here.