Vscode: Electron 3.0.x: Pale/desaturated colors
⚠️ bpasero: ⚠️
This will be fixed in Electron 4 when via @poiru https://github.com/electron/electron/pull/15898. Please expect Electron 4 to be out in 2-3 months.
If you cannot wait until then, consider to use our exploration builds that already ship with Electron 4:
We are building exploration builds (you might need to update from within once to get latest) that use a much newer version of our UI framework (Electron version 4.0.x). I wonder if this issue reproduces with one of these builds, could you try? Download:
Original Issue:
- VSCode Version: 1.31.0
- OS Version: macOS 10.14.2
Same as https://github.com/atom/atom/issues/17356
The new color profile makes the editor appear desaturated compared to the previous version. Is there an option to use the previous sRGB profile again? (Atom's checkbox doesn't actually work)
Does this issue occur when all extensions are disabled?: Yes
atomiks
All 33 comments
(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:
![vscodebot[bot] picture](https://avatars2.githubusercontent.com/in/2406?v=4&s=40)
vscodebot[bot]
on 6 Feb 2019
Seconding this on Ubuntu 18.04.
To be clear, this isn't a _subtle_ change. The new colors are actually _more_ vibrant, which is absolutely not what I want. I have a theme with pastel colors, and this change renders some text nearly illegible.
jhpratt
on 6 Feb 2019
Before update (now taken from Android Studio where I have my color scheme and where I copied the colors from):
After update:
In particular, some shades of green are now indistinguishable.
But before the update, I copied the colors from Android Studio using screen color picker, and now I can obtain the same colors by copying hex values. Which means that at least now VSCode uses the same color matching mechanism.
I'm on MacOS 10.13.6 and use a wide-gamut monitor.
kika
on 7 Feb 2019
I'm also seeing this on MacOS 10.14.2 on a 2017 Macbook Pro monitor using the Dark Molokai Theme:
Before update (v1.30.2)
After update (v1.31.0)
It's a kind of subtle change but it's definitely noticeable. Like @jhpratt I have a vibrant colour theme for a reason, I need the high contrast for usability.
Edit: I've simply downgraded to v1.30.2 and will keep it there until this is fixed.
sam3d
on 7 Feb 2019
Also getting this after upgrade on MacOS 10.14.2 and my 2017 Macbook Pro with Atom One Dark theme. Colors are considerably less saturated.
tannergaucher
on 7 Feb 2019
This will be fixed in Electron 4 via @poiru https://github.com/electron/electron/pull/15898. Please expect Electron 4 to be released in stable in 2-3 months.
If you cannot wait until then, consider to use our exploration builds that already ship with Electron 4:
We are building exploration builds that use a much newer version of our UI framework (Electron version 4.0.x). I wonder if this issue reproduces with one of these builds, could you try? Download:
bpasero
on 7 Feb 2019
The darwin exploration build still has the desaturated colors. I'm also noticing some color artifacts in the editor background on 1.31 on the right side in the form "tiles" around where the line selection is, which appear to be fixed in the darwin build. Does there need to be a checkbox to use the old color profile?
For anyone wanting the vibrant colors back, on macOS, you can set the whole OS to use sRGB in System Prefs > Displays > Colour:
This has the side effect of making everything in the OS appear overly vibrant/saturated, something that I only like in my editor for the bright syntax highlighting...
atomiks
on 7 Feb 2019
@poiru is there anything else required than:
app.commandLine.appendSwitch('disable-features', 'ColorCorrectRendering');
bpasero
on 7 Feb 2019
@bpasero You need to switch to app.commandLine.appendSwitch('disable-color-correct-rendering').
poiru
on 7 Feb 2019
I pushed this change to the exploration build. Can someone verify?
bpasero
on 7 Feb 2019
Not 100% sure I'm dealing with the same issue, but it looks unchanged. Downloaded Exploration build 1 minute ago.
Version: 1.31.0-exploration
Commit: 37818ac3597b4afda264b05226b0b77fb8e85f41
(Is the link in the first post still correct for Linux? Where can I find a more generic landing page for Exploration build?)
Just wanted to share that this is a blocking issue for me. Call me a broken human but this faded colour is more distracting to my job than a fire alarm going off. I eagerly hope we can help get this fixed in any build. Otherwise I'll seek info on how to revert to 1.30 for the next 2-3 months. Thanks for your help!
ablakey
on 7 Feb 2019
@ablakey should mention, those links are old and you need to update once to get latest!
bpasero
on 7 Feb 2019
Derp. Of course!
You might have to take my word for it. It is noticeably better to my eyes. The background is distinctly darker.
ablakey
on 7 Feb 2019
So I did something unconscionably awful.
I didn't want to use a different version of code because I didn't want to migrate all of my settings, extensions, etc. over.
In /usr/share/code/resources/app/out/main.js I replaced:
app.commandLine.appendSwitch("disable-features", "ColorCorrectRendering");
with:
app.commandLine.appendSwitch('force-color-profile', 'srgb');
(via sed or your favourite editor with sudo privileges)
This probably relies heavily on my computer's environment settings, the monitor's profile, and whatnot. So I anticipate this is not a globally useful solution.
This modifies built code in /usr/share/ which is preeeeetty awful. But it works. I expect it will get clobbered when vscode gets updated next. I can't understate how "wrong" this is. But it solved my problem very easily and may help others.
ablakey
on 8 Feb 2019
Just for the record, --force-color-profile=srgb does not work on macOS.
poiru
on 8 Feb 2019
@ablakey's fix worked for me too on Ubuntu 18.10
Zeex
on 9 Feb 2019
Just tried the exploration build for macOS and this does not appeared to be fixed there. Is there a more up-to-date exploration build we should be trying?
I have tried build 37818ac3597b4afda264b05226b0b77fb8e85f41.
dhowden
on 25 Feb 2019
Are my eyes going bad or does this appear to be fixed in the latest release? Either that, or this issue isn't replicated in Bionic, which I switched to recently.
ablakey
on 18 Mar 2019
I've been switching back and forth between the recent versions (back to 1.30.2). I still see the same issue.
Which version are you trying?
dhowden
on 18 Mar 2019
I can confirm it's fixed in the macOS download link version (after updating it) and the colors are vibrant again 🌈. When does that version go stable? I've been staying on 1.30.2
atomiks
on 2 Apr 2019
I'm on Fedora 29, VSCode 1.33.0 and colours are still weird unless I force the colour profile to become sRGB.
Another temporary fix I've found is to override the _.desktop_ file by copying it to ~/.local/share/applications and then adding --force-color-profile=srgb at the Exec line in code.desktop, like so
Exec=/usr/share/code/code --force-color-profile=srgb --unity-launch %F.
You might have to restart your desktop environment for this to take effect.
nchengyeeshen
on 9 Apr 2019
This will be fixed in Electron 4 via @poiru electron/electron#15898. Please expect Electron 4 to be released in stable in 2-3 months.
@bpasero Any updates, or an ETA on when Electron 4 will ship beneath Code? _Every single update_ forces me to pull this issue back up to find the necessary file and flag I need to switch. At the very least, putting in an option to toggle it would be great.
jhpratt
on 11 Apr 2019
@bpasero
I'm interpreting a lack of response (given your activeness on GitHub) as "we have no timeframe", which is a shame, really. Tons of people are affected by this, and there's no effort to change it.
Upgrading to Electron 4 is the suggested solution, but _this has been deferred_ past the April release (due to come out May 6), per #71830. Your estimated timeframe was 2-3 months, and the release on May 6 is the long end of that. I (along with others) would very much appreciate an updated estimate.
At the absolute least, adding a dropdown in the settings to toggle the rendering would solve the issue temporarily.
jhpratt
on 18 Apr 2019
It seems like the only thing blocking the upgrade is #69301. No response since February from Electron team :\
atomiks
on 18 Apr 2019
@jhpratt I have just triggered a new Exploration build with latest changes. Have you considered staying on that version until we did the move?
Download:
bpasero
on 18 Apr 2019
As for the setting: since this is something that needs to be set very early on on startup, we do not have access to our settings file yet. Since startup performance is critical to us, we (so far) have stayed away from blocking the startup to read the settings file.
bpasero
on 18 Apr 2019
@bpasero Has the latest exploration build broken this again? This was working fine, seems to have stopped working for me today. I updated to macOS 10.14.5 last night, so that might have caused the problem (hope not, less likely to be fixable!).
Edit: I'm running Version 1.35.0-exploration (1.35.0-exploration) (1bdebe7e66e42d73b62c578b46fdc9a3e84c99d5)
dhowden
on 22 May 2019
@deepak1556 maybe knows
bpasero
on 22 May 2019
Are people (@atomiks) still seeing this with latest VSCode insider builds? You can give our preview releases a try from: https://code.visualstudio.com/insiders/
Those have been updated to Electron 4. Just curious.
bpasero
on 11 Jun 2019
Nope, the desaturated colors and artifact problem are both gone in the latest builds with Electron 4
atomiks
on 12 Jun 2019
I cannot reproduce the issue on latest insiders.
On Tue, Jun 11, 2019, 12:16 PM Benjamin Pasero notifications@github.com
wrote:
Are people still seeing this with latest VSCode insider builds? You can
give our preview releases a try from:
https://code.visualstudio.com/insiders/Those have been updated to Electron 4. Just curious.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode/issues/68001?email_source=notifications&email_token=ACE2T6FDQKYI6FKUYJMVEZTPZ7FXNA5CNFSM4GUX5ZL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXNVROA#issuecomment-500914360,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACE2T6EKYJNOWSVV475V43TPZ7FXNANCNFSM4GUX5ZLQ
.
ablakey
on 12 Jun 2019
We will ship with Electron 4 with our upcoming release 1.36 this week. As such I am closing this issue. To benefit from the update already today, consider to use our insiders version: https://code.visualstudio.com/insiders/
bpasero
on 1 Jul 2019
Running the latest insiders, looks like the color saturation issue has returned... Reporting here as it is related, apologies if this should be a new issue!
Version: 1.37.0-insider
Commit: 894056d11c7fffb261a0100fd4dcbf8cff84a8c0
Date: 2019-07-15T05:24:02.940Z
Electron: 4.2.5
Chrome: 69.0.3497.128
Node.js: 10.11.0
V8: 6.9.427.31-electron.0
OS: Darwin x64 18.6.0
dhowden
on 16 Jul 2019
Related issues
trstringer
·
3Comments
curtw
·
3Comments
mrkiley
·
3Comments
VitorLuizC
·
3Comments
chrisdias
·
3Comments
Most helpful comment
So I did something unconscionably awful.
I didn't want to use a different version of code because I didn't want to migrate all of my settings, extensions, etc. over.
In
/usr/share/code/resources/app/out/main.jsI replaced:with:
(via
sedor your favourite editor with sudo privileges)This probably relies heavily on my computer's environment settings, the monitor's profile, and whatnot. So I anticipate this is not a globally useful solution.
This modifies built code in
/usr/share/which is preeeeetty awful. But it works. I expect it will get clobbered when vscode gets updated next. I can't understate how "wrong" this is. But it solved my problem very easily and may help others.