Some colors from themes render slightly differently than defined

[izuzak]

Check for existing issues

• [x] Completed

Describe the bug / provide steps to reproduce it

I'm working on a theme and setting the syntax.property.color value to #2C78BF. And I see the color of those UI elements change, but the color is slightly different as reported by the color picker -- it says the color is #2D78BF. See first screenshot.

I don't notice this for every color, though -- the color for syntax.string.color is #98BC37 and the color picker reports exactly that value. See second screenshot.

The behavior doesn't seem to be related to which UI/syntax property the color is associated with, but with the color itself. E.g. if I set syntax.string.color to #2C78BF, then it still comes out "wrong" as #2D78BF.

I mentioned this in the Zed discord channel and @maxdeviant said:

I've noticed something similar before. There's a loss of precision somewhere in the mix as colors get converted back and forth between representations that results in some variance.

This was when I noticed the problem originally, during the GPUI 2 rewrite: https://github.com/zed-industries/zed/pull/3547. At the time we were experimenting with importing VS Code themes into Zed, and I noticed that the hex colors weren't round-tripping properly. The fix added in that PR made it so the colors (at least, all the ones I manually checked) were able to round-trip through the theme pipeline and come out the other end in the same form.

We're still using that same approach when parsing hex colors from JSON themes: https://github.com/zed-industries/zed/blob/85e6bc94e980bd91a69ef2ed5cb0372cc4e35667/crates/theme/src/schema.rs#L14-L27. But I'm not sure if there's some other spot where we might be losing precision.

It's a bit of a rabbit hole, because when I was trying to debug it initially I realized that sometimes the colors don't even match up with what the macOS color picker says they are if you're in a different color space 😅

Environment

Zed: v0.126.0 (Zed Preview) OS: macOS 14.3.1 Memory: 64 GiB Architecture: aarch64

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

Screenshot 1:

Screenshot 2:

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

No response

[SkyeX]

This is likely an issue with the color space/management set by the individual system rather than a loss of precision. The ideal solution would be to encode everything in a Linear color space and convert it to the system color space on render.

Not to mention that most color spaces are based on numerical rather than perceptual properties, so there is a lot of variation between devices. Adopting a perceptual color space like OK Lab would help maintain perceived color across implementations.

[github-actions[bot]]

Hi there! 👋 We're working to clean up our issue tracker by closing older issues that might not be relevant anymore. Are you able to reproduce this issue in the latest version of Zed? If so, please let us know by commenting on this issue and we will keep it open; otherwise, we'll close it in a week. Feel free to open a new issue if you're seeing this message after the issue has been closed. Thanks for your help!

[izuzak]

Are you able to reproduce this issue in the latest version of Zed?

Just tested it, and yep -- it's still a problem. :v:

[thataboy]

I've noticed this too. Here's my example

Screenshot of my theme file. The cursor should be #fff080. But if you use a color picker on the block cursor you'll see it came out as #FFED67

Zed: v0.158.0 (Zed Preview) OS: macOS 14.6.1 Memory: 16 GiB Architecture: aarch64

This is a bit annoying since you can arefully tweak your theme colors and you won't get the colors you expect, and imported themes won't look quite the same.(colors usually dimmer and/or duller).

[MadLittleMods]

Here is another example but with some transparency. The theme defines "search.match_background": "#ea5c0055" but it appears incorrectly over top of an opaque white (#ffffff) background; a lot more dim/dull/muted and washed out.

(we're just comparing the orange search highlights here)

Zed on Linux (dim as #f8dad5)	Zed on macOS (normal as #f8c9aa)	VSCode on Linux (baseline expected as #f8c9ab)

Linux machine details:

• Zed 0.172.9
• Manjaro Linux (arch-based)
• XFCE desktop environment (X11)
• 3840x2160 resolution - at 1x scale (non-retina monitor (low DPI))
• Fira Code font (via the ttf-fira-code package)

macOS details:

• Zed 0.173.10
• macOS 15.1.1
• 3072x1920 resolution - Macbook Pro 16-inch 2019
• Fira Code font (via brew install font-fira-code)

[mark-newton]

I believe it's the colorspace on macos - I use neovim and had to adjust the colorspace settings in my terminal config to get it to render the theme colors correctly (eg. #1b1e28 would render as #1c1e27). My kitty terminal settings to fix this is macos_colorspace displayp3.

[ja1ns]

I am also observing the same issue, ported "One Dark Pro" theme from vscode to zed, the colours in zed are looking dull

Attaching the ported theme json file as well

one_dark_binarify.json

[Abhinav5383]

erm, when is this gonna be fixed? seems like it's been open for over an year now

VS Code	Zed

That is just one example, a lot of the colors from the theme look just ugly

0x00 to 0x06 becomes 0x00, 0x07 to 0x11 becomes 0x05, 0x12 to 0x19 becomes 0x10 and so on

[kaspar030]

I'm observing this on a current Arch linux with Gnome / Wayland. ... unfortunately makes the editor unusable. :(

vim:

zed:

(Themes are different it seems, but the zed text looks washed out in all themes)

[erikas-taroza]

Getting this issue as well. Its pretty obvious with my editor background compared to the other colors. However, my issue appeared after an update. It wasn't always like this. Unfortunately, I don't remember when I first ran into this problem.

[neoduck0]

Got the same issue on arch linux 6.15.4-arch2-1 and zed 0.193.3-1, I set the background to #282828 and get back #232323.

[LeVraiArdox]

up, same on arch, zed 0.198.5-1, #0F1512 is replaced by #051010

[dhemasnurjaya]

I had this issue on my Linux (using KDE Wayland), asked Gemini and found temporary workaround:

env -u WAYLAND_DISPLAY zeditor

it will force Zed to run under X11, so you will have issue with fractional scaling when using multiple monitors with different scaling. But for me it fixed the colors

[Abhinav5383]

woah, it does get fixed under xwayland/x11 so it's a not an issue with color conversion but with wayland idk

[ja1ns]

any eta for fix on mac or windows ?

[hoywu]

same on ArchLinux/Hyprland (wayland), the background #1F1F1F turned into #181818, and fixed under Xwayland.

[wildwestrom]

Happening under NixOS/Sway (wayland). I knew they looked washed out.

[torarnv]

I'm guessing most editors are not color managed, meaning the #ff0000 in a theme will be the most vibrant red the screen can produce. While zed most likely tags its output as sRGB, which on macOS will result in the OS color managing it to fit within the likely larger color space of the display (P3 e.g.), looking dull in comparison to the unmanaged editor. Can we have an option to set the color space for zed's rendering, or at least let some of the theme colors not be clamped to sRGB?

[MrSubidubi]

Thanks for everyones input here. That does not seem optimal at all, and definitely is something we should take a look at.

However, from taking a look at the comments here, while the end-result seems to be the same for many of you, some of you might actually be affected by other issues, namely:

• https://github.com/zed-industries/zed/issues/7992
• https://github.com/zed-industries/zed/issues/13564 and
• https://github.com/zed-industries/zed/issues/33295

Just for your information that once this issue is resolved, you might actually still be affected by one of these.

In any case, thank you everyone for the discussion and input!

[MrSubidubi]

I just took another brief look and it seems that I am unable to reproduce ~~the original issue as well as~~ https://github.com/zed-industries/zed/issues/9057#issuecomment-2986322974 on MacOS.

---

~~Thus, I'd appreciate some feedback: Please mention your OS/distro as well, so we can determine whether this might actually be one of the other issues I referenced above. Thanks!~~

Edit: I was able to reproduce the original issue still - it seems like the color in e.g. screenshots is correct, yet the actually displayed color is off. Sorry for the noise and thanks for the reports!

[torarnv]

@MrSubidubi Thanks for testing! A quick test would be to make the text or background color #ff0000, which should result in 255,0,0 in a screenshot or when using the native color panel eye dropper (taking advantage of the full range of whatever color space the display is configured as).

Down the line, themes could potentially treat #ff000 an an sRGB (muted) red, if we teach the theme parser about color(display-p3 1 0 0) so that you can still choose colors outside of sRGB. Though for theme compat between other themes it probably makes sense to let the theme configure the target color space globally for the theme.

[torarnv]

@MrSubidubi Any tips on where to start looking to backtrack from how the CAMetalLayer is configured and back through the pipeline to see where the clamping of the colors happen?

[MrSubidubi]

@torarnv Not particulary an area of the codebase where I have much knowledge in to be honest. Yet, if you wanted to start looking into that, this will sit deep within the GPUI code, much likely crates/gpui/src/platform/mac/metal_renderer.rs and more specifically the folder would be the naive and best start to search for this.

Sorry I can't be of much more help here though 😅