Vscode: [mitigated] HDR Screen Dim

[AzureWolf]

• VSCode Version: 1.42.0-insider (user setup)
• OS Version: Windows_NT x64 10.0.19041

Steps to Reproduce:

1. Open VSCode on Win 10 with an HDR screen

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

I know this issue was resolved previously (https://github.com/microsoft/vscode/issues/68069 and https://github.com/microsoft/vscode/issues/72373). The --force srgb trick still works, but for the past few weeks it was not necessary.

[connor4312]

@deepak1556 looks like this was fixed originally by an electron update, something regress here?

[AzureWolf]

Just wanted to update that the latest update still has this issue. --force srgb still works but had to reimplement it.

[deepak1556]

Seems like a regression from upstream chromium, will have to wait for a fix from them. https://bugs.chromium.org/p/chromium/issues/detail?id=1038770

[bpasero]

If we cannot get a fix, we should make sure force-color-profile is a supported option for argv.json (https://github.com/microsoft/vscode/blob/3aa5383/src/main.js#L128)

[AzureWolf]

If we cannot get a fix, we should make sure force-color-profile is a supported option for argv.json (https://github.com/microsoft/vscode/blob/3aa5383/src/main.js#L128)

I second this. I love that you guys are updating and working on this amazing free software, but it's admittedly annoying and inconvenient to have to keep putting this in. At the very least, stop re-creating the shortcut after updates?

[bpasero]

@AzureWolf can we try out something:

• close any running instance of VSCode
• download https://az764295.vo.msecnd.net/insider/7428f161b0def9c82f5582b977f837fb0ad63453/VSCode-win32-x64-1.42.0-insider.zip and unzip and run
• quick open command palette and pick "Configure Runtime Arguments"
• replace the file with the contents below [1] (ignore the warning)
• close
• start same version again

I am trying to figure out if the --force-color-profile srgb works when passed in programmatically so that you do not have to specify it each time from the command line.

[1]

{
    "disable-color-correct-rendering": true,
    "force-color-profile": "srgb"
}

[AzureWolf]

Hey sorry I just saw this. The issue seems to have been resolved. I also tested what you asked @bpasero and it doesn't appear to work (tested by following your instructions, that version is still dark, and running and re-running does not resolve it).

So it seems like it's resolved and hopefully won't be an issue? I don't know what changed.

[deepak1556]

@AzureWolf we reverted to electron 6 in master, so its temporarily fixed in the insiders, but based on the original issue it should reappear once we get electron 7 update again. The chromium issue is still open but I will backport a potential fix the chromium authors mentioned. I can get a custom build some time today or tomorrow, would be great if you can test that.

[AzureWolf]

Sure happy to help!

[bpasero]

@AzureWolf ok let's try that experiment again if you can. There is a newer build available [1]

• close any running instance of VSCode
• download [1]
• quick open command palette and pick "Configure Runtime Arguments"
• replace the file with the contents below [2]
• close
• start same version again

=> are the colors better?

[1] https://az764295.vo.msecnd.net/insider/a1f569c66f67287c525ee50b5f46ced8a50b4551/VSCode-darwin-insider.zip

[2]

{
    "disable-color-correct-rendering": true,
    "force-color-profile": "srgb"
}

[bpasero]

@AzureWolf ping

[bpasero]

I pushed support for configuring the color profile via our runtime arguments file. Steps to enable this:

• use command palette to find runtime arguments command [1]
• add "force-color-profile": "srgb" to the end of the file
• restart

[1]

[AzureWolf]

Hey super sorry. I'll check it out when I get a chance. For now I just removed HDR from my monitor settings so I have to set that up again when I'm not busy. It was a real pain to see a daily loss of brightness at the start of the day and it's been busy. I'll let you know.

Very sorry about that

[AzureWolf]

Hey just tested this out and it does and doesn't work. So putting "disable-color-correct-rendering" to false fixes the issue. Setting it to true does not resolve the issue. Setting it to true and adding the color profile (as the screenshot you see here) does not fix the issue.

Thank you so much for this! I can finally go back to using HDR on my monitor! I don't know what it is, but it doesn't really make a big difference but all the colors are "softer" or less intense except where appropriate. It's hard to describe, but it makes it easier to work longer, so I'm super grateful. I'll be sure to thank you guys wherever possible. You guys are an amazing team making an exceptional and free product.

EDIT: may be a stupid question, but the other application I'm experiencing this issue on was mpv (the video player). Any chance you know what would be the equivalent setting there?

[bpasero]

@AzureWolf thanks for giving this a try. Since you see yellow squigglies in the editor I wonder if you maybe tried with VSCode stable and not insiders? Can you recheck this with our insiders build?

You can give our preview releases a try from: https://code.visualstudio.com/insiders/

You should not see a yellow warning like that which indicates that this property is not being applied.

[AzureWolf]

I'm using Insiders:
Version: 1.43.0-insider (user setup)
Commit: 07c33977da255861edf71e65b18249d2f67d0762
Date: 2020-02-24T05:33:18.353Z
Electron: 7.1.11
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Windows_NT x64 10.0.19041

[seanthegeek]

This regression is still present in the 1.43 final release and 1.44 insiders. It looks like the upstream Chromeium bug mentioned by @deepak1556 has been fixed upstream just 16 days ago. @bpasero can you integrate that fix? I'm not even sure if it has made it's way into a stable release of Chromium or Electron yet though.

[SidShetye]

Can VSCode have a unit test around HDR to prevent these regressions? This isn't the first time this issue has been reported. This is happening again on 1.43

Version: 1.43.0 (user setup)
Commit: 78a4c91400152c0f27ba4d363eb56d2835f9903a
Date: 2020-03-09T19:47:57.235Z
Electron: 7.1.11
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Windows_NT x64 10.0.18363

[michaeljota]

@seanthegeek @SidShetye See the releases notes

[Varstahl]

I can confirm this issue reappearing today for me with 1.43, and that the workaround in the release note works. What I don't understand is why 1.43 was fine up to some hours ago, then stopped working properly as soon as I moved from Edge 44 to Edge 80. How is the installation of Edge even connected to VSCode in the first place… Oh, well…

[seanthegeek]

@Varstahl It shouldn't be related to Edge at all. Maybe the Edge install turned on HDR in Windows? Or maybe you turned on HDR and forgot?

[Varstahl]

I always have HDR active having an HDR monitor, and the original problem followed #68069 (bright and washed out colors) and was fixed up to today. Then, today, after moving from legacy to recent Edge, the issue appeared in a different form: now it's like there's a black overlay plus some artifacts in the text editor. It's fixed as per the other issue with --force-color-profile srgb, just as with the disable-color-correct-rendering option.

I've tried re-installing the latest version of Code as well as trying the insider, but still the same issue, after updating to Edge 80 the issue started in Code (and in Code alone). Weird.

Edit: realistically shopped screenshot for reference

[seanthegeek]

@varanshukla I had the same problem. The new workaround for VSCode 1.43 is different than the past ones you are talking about.

From the release notes section @michaelchiche linked to:

In the meantime, we have a temporary workaround for this issue:

1.Open the Command Palette (Ctrl+Shift+P).

1. Run the Preferences: Configure Runtime Arguments command.
2. This command will open a argv.json file to configure runtime arguments. There might be some default arguments there already.
   
   
   
   1. Edit "disable-color-correct-rendering": true to "disable-color-correct-rendering": false.
   
   
3. Restart VS Code.

[Varstahl]

@seanthegeek assuming you were replying to me, yeah, I know. As I said both the runtime option and the force srgb command parameter fix that issue, I've already applied the change to argv.json myself. I was merely reporting the issue because I never saw screens like it and because it happened after installing Edge, which is something I still can't wrap my head around.

[Jaegermeiste]

I'm on 1.43 with HDR enabled and FreeSync. Issue cropped up after update, but @bpasero's force-color-profile : srgb DID work for me and resolve the issue without changing disable-color-correct-rendering, which remains true.

[Kissaki]

Resurfaced after updating to 1.43.

To clarify what the workaround is, that works for me as well:

Open the "Preferences: Configure Runtime Arguments" action which opens the argv.json file and add the setting "force-color-profile": "srgb".

Disabling disable-color-correct-rendering did improve/change the rendering but did not really fix the contrast issue. With the above workaround this setting can be left at true.

[seanthegeek]

@Kissaki "force-color-profile": "srgb" is the best fix, instead of disable-color-correct-rendering. It also fixed the screenshot problem I reported in issue #92365. Thank you!

[fidonet]

Just to note that this is still an issue in 1.46.1

You can see the contrast difference (and the bizarre random white box) between the VS Code window and a normal Windows UI window it's sitting on top of ..

[deepak1556]

The issue should be fixed in latest insiders https://code.visualstudio.com/insiders/, please verify by removing any workarounds added via argv.json

[seanthegeek]

@deepak1556 Verified fixed in Insiders. Thanks!

[phillipo6]

Still exists for me with the insiders version, as long as i have vs code windowed it works, but as soon as i go to fullscreen the screen dims.

[deepak1556]

Sorry about that, we have reverted the runtime which contains the fix for this iteration. The fix will be available again from next week once we update to Electron 9 in master.

[NikilRagav]

Hi this is still broken for me

Not sure if it can be seen but most of the screen is dim except for a couple of blocks where there is no text

For what it's worth, other electron apps that I use don't have these problems

[NikilRagav]

I edited my runtime args disable-color-correct-rendering to false and now things work. Granted, I have no idea if it is "correct".

Both of my screens (internal laptop 4k OLED w/ HDR and external 4k LCD no HDR) support DCI P3. Would like to make sure my colors are correct.

[deepak1556]

The upstream fix will be available with upcoming stable release and is already available with current insiders, please check. Thanks!

[DIGITALCRIMINAL]

Putting "force-color-profile": "srgb" in argv.json fixed it for me

(Samsung G9 HDR full brightness)

[rtheil]

This has finally been fixed in 1.49.1 with Electron 9.2.1