-
Notifications
You must be signed in to change notification settings - Fork 3.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Font rendering on LoDPI displays #7992
Comments
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. |
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. |
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. |
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: ***@***.***>
|
I am having the same issue on a HighDPI screen (Linux). Please let me know if screenshots are needed |
Same issue as @JackNWhite but in vscode |
I tried few dark and light themes and the issue is much more noticeable on the light themes |
Same issue here in LoDPI LCD screen(Laptop). I'm using Fedora 40, and installed Zed from the installation script. |
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. 🙏🏼 |
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. |
@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. |
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. |
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. |
Switched back to SublimeText due to this issue. |
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.
Anything subpixel cannot work on a modern system due to scaling and rotation. GTK4 has completely removed subpixel rendering for that reason AIUI. |
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 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. |
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 :) |
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. |
IGNORE: I had the wrong config. The issue got resolved when I changed UI and Buffer font settings |
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. |
👋 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. |
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.)
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. |
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. |
For me is a matter of usability and accessibility. I get literal headaches after a few minutes from the non-crisp 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. |
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. |
I actually use COSMIC and the font rendering is absolutely fantastic, so this indeed seems to be a Zed-specific issue here. For me, COSMIC is a lot better at rendering fonts (even after tweaking Fontconfig) than KDE, which is slightly weird and blurry, and GNOME, which looks abysmal with 150% scaling. |
Downloaded manually: https://zed.dev/api/releases/stable/latest/zed-linux-x86_64.tar.gz
Ergo, this appears to be something distro-specific (for Linux), maybe some old font libraries (freetype2/fontconfig/harfbuzz) or their settings. |
I am on Arch Linux, I don't think I have old font libraries. |
Thanks everyone for chiming in on this and providing feedback! 🙏 I took a stab at fixing this for macOS in #20506. As mentioned by @dfrg, I believe this is an issue with gamma correction. Here’s a dev build for that pull request (https://github.com/zed-industries/zed/actions/runs/11783849253/artifacts/2172770346), I would love if people could give it a shot! Please note that this won't fix the issue with anti-aliasing bitmap fonts. If the dev build still doesn't work as expected, it would be really helpful for me to have access to the following information:
The screenshots should be as simple as possible, ideally without syntax highlighting. If the difference is only visible with syntax highlighting, please provide the snippet and language you tested Zed with. |
The above looks the same to me 🤷♂️ |
The text looks sharper, but the spacing between some characters is a little uneven. The screenshots below show a comparison between Zed, Zed Dev, and VS Code (1080p resolution, 12px font size, default light theme). The word Zed logs2024-11-16T17:51:15.593294+01:00 [INFO] ========== starting zed ========== 2024-11-16T17:51:15.661851+01:00 [INFO] Opening main db 2024-11-16T17:51:15.664253+01:00 [INFO] Opening main db 2024-11-16T17:51:15.670614+01:00 [INFO] Using git binary path: Some("/Volumes/Zed/Zed Dev.app/Contents/MacOS/git") 2024-11-16T17:51:15.940714+01:00 [INFO] set environment variables from shell:/bin/zsh, path:REDACTED 2024-11-16T17:51:15.942059+01:00 [INFO] No prompt template overrides directory found at /Users/christian/.config/zed/prompt_overrides. Using built-in prompts. 2024-11-16T17:51:15.94342+01:00 [INFO] extensions updated. loading 1, reloading 0, unloading 0 2024-11-16T17:51:16.00802+01:00 [INFO] Opening main db 2024-11-16T17:51:16.025304+01:00 [INFO] !!!!!! SCALE FACTOR 1.0 2024-11-16T17:51:16.045003+01:00 [INFO] set status on client 0: Authenticating 2024-11-16T17:51:16.058525+01:00 [INFO] Opening main db 2024-11-16T17:51:16.062805+01:00 [INFO] set status on client 107552: Connecting 2024-11-16T17:51:16.074746+01:00 [INFO] Opening main db 2024-11-16T17:51:16.277027+01:00 [INFO] connected to rpc endpoint https://collab.zed.dev/rpc 2024-11-16T17:51:16.320294+01:00 [INFO] starting language server process. binary path: "/Users/christian/.n/bin/node", working directory: "/", args: ["/Users/christian/Library/Application Support/Zed/copilot/copilot-v0.5.0/dist/agent.js", "--stdio"] 2024-11-16T17:51:16.546048+01:00 [INFO] Language server with id 0 sent unhandled notification LogMessage: { "level": 0, "message": "[DEBUG] [agent] [2024-11-16T16:51:16.543Z] Agent service starting", "metadataStr": "[DEBUG] [agent] [2024-11-16T16:51:16.543Z]", "extra": [ "Agent service starting" ] } 2024-11-16T17:51:16.54881+01:00 [INFO] Language server with id 0 sent unhandled notification client/registerCapability: { "registrations": [ { "id": "fb0c0dc6-9613-430a-ad2a-982b46041f80", "method": "workspace/didChangeWorkspaceFolders", "registerOptions": {} } ] } 2024-11-16T17:51:16.572948+01:00 [INFO] Language server with id 0 sent unhandled notification LogMessage: { "level": 0, "message": "[DEBUG] [agent] [2024-11-16T16:51:16.551Z] Telemetry initialized", "metadataStr": "[DEBUG] [agent] [2024-11-16T16:51:16.551Z]", "extra": [ "Telemetry initialized" ] } 2024-11-16T17:51:16.80538+01:00 [INFO] add_connection; 2024-11-16T17:51:16.815429+01:00 [INFO] set status on client 107552: Connected { peer_id: PeerId { owner_id: 607, id: 705611 }, connection_id: ConnectionId { owner_id: 0, id: 0 } } |
Thanks so much @Grabber and @klaussner! I tweaked the pull request a bit and would love if you could give the latest build a try: https://github.com/zed-industries/zed/actions/runs/11893780331/artifacts/2201854238. It should solve the issue with the weird positioning. |
I would love to try this, but as I understand it, it doesn't fix this for Linux? And I don't have a mac. |
@as-cii |
@as-cii In the latest build, the text looks almost identical to the stable build. This video compares both versions (dark text is slightly darker in Zed Dev): Zed.comparison.mp4 |
Yes, the first dev build was better than the second.
…On Wed, Nov 20, 2024, 12:01 Christian Klaussner ***@***.***> wrote:
@as-cii <https://github.com/as-cii> In the latest build, the text looks
almost identical to the stable build. This video compares both versions
(dark text is slightly darker in Zed Dev):
https://github.com/user-attachments/assets/8f1201e9-10af-4957-abca-2359203e4a6c
—
Reply to this email directly, view it on GitHub
<#7992 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAD24YRRPXWOB4YAC5J2ND2BSP37AVCNFSM6AAAAABDOO5R3WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOBYHAYTKMRZHA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Check for existing issues
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
The text was updated successfully, but these errors were encountered: