Allow to disable hardcoded color profile selection

[lediur]

• VSCode Version: 1.25.0-insider fa7ded2f007be6ae288b29392501f3dc34105abd (with Electron 2.0.2)
• OS Version: Windows 10 Pro 17134

Steps to Reproduce:

0. Use monitors with specific color profiles (I have two external monitors and a laptop screen, all of which use different profiles corresponding to sRGB)
1. Open VSCode. Colors are rendered correctly.

2. Disconnect and reconnect monitors.
3. VSCode / Electron refreshes color profiles and starts rendering colors incorrectly (washed out as if rendering sRGB on a display expecting Adobe RGB)

4. If you restart VSCode Insider (may have to restart all other instances of VSCode, including stable), the colors are correct again until monitor configuration is changed

Does this issue occur when all extensions are disabled?: Yes

May be related to electron/electron#10732 and recent upgrade to Electron 2 (VSCode stable 1.24.0 doesn't exhibit this issue).

[thomasjo]

See atom/atom#17380.

[bpasero]

@lediur can you give this a try:

• quit any running VSCode Insiders
• open C:\Program Files\Microsoft VS Code Insiders\resources\app\out\main.js
• find the place where it reads app.commandLine.appendSwitch("disable-mojo-local-storage");
  right after paste this: app.commandLine.appendSwitch('force-color-profile', 'srgb');
• save (you will need to save as admin I guess)
• start VSCode Insiders again
  => does the issue still reproduce?

[lediur]

Thanks for the heads up @bpasero. I saw that workaround earlier in the aforementioned atom and electron issues but wasn't sure how to inject that into an installed version of VSCode.

I tested out the workaround and can confirm the issue no longer occurs.

[lediur]

Hmm, I just unplugged my laptop without reconnecting to monitors and the issue actually appears to not have been fixed with that change. nevermind, it's because I updated VSCode.

[bpasero]

@jasonrudolph @daviwil may I ask: any reason you guys decided to not change the default in atom/atom#17380 to be 'force-color-profile': 'srgb'? Is there a benefit from leaving this as Chrome decides to that you are aware of?

[jasonrudolph]

any reason you guys decided to not change the default in atom/atom#17380 to be 'force-color-profile': 'srgb'? Is there a benefit from leaving this as Chrome decides to that you are aware of?

@bpasero: I have to admit that my experience working with color profiles is essentially nonexistent prior to atom/atom#17380, but I'll try to explain our thinking. 😅

Assume a developer has taken the time to calibrate the color profile for their display. As a result, they see that Photoshop (and various other apps) respect that color profile and render colors accordingly. The user has said, "When rendering colors on this display, apply these adjustments to ensure that colors are rendered correctly." If Atom always forces the color profile to sRGB, Atom is ignoring that user's instructions, and the user has no way to get Atom to render colors in accordance with the color profile. 🙁

With that in mind, we've chosen to respect the color profile by default. For the subset of users that want apps like Photoshop to honor their color profile, but want Atom to ignore the color profile, we provide a configuration option that allows those users to force the color profile to sRGB in Atom. 🎨 🙂

I hope that context is helpful.

For what it's worth, I found this doc from the Chrome team (shared in electron/electron#10732 (comment)) to be a valuable reference in understanding the background for Chrome's updated handling of color profiles.

[bpasero]

@jasonrudolph thanks, that document is really helpful. It looks like not changing the defaults and having a setting is the right thing to do.

[bpasero]

@lediur if you have the time could you see if VSCode Exploration also looks good to you in terms of colors? It includes a variant of the fix on a newer Electron version that should restore the old behaviour completely.

[bpasero]

Closing, with the update to 2.0.7 we are back to the Electron 1.7.x behaviour.