Vscode: Dim window while using Win10's HDR

[Euruson]

Issue Type: Bug

The window is really dim while using Win10's HDR. However, VS2017 works fine.

VS Code version: Code 1.31.0 (7c66f58312b48ed8ca4e387ebd9ffe9605332caa, 2019-02-05T22:35:56.624Z)
OS version: Windows_NT x64 10.0.17134

System Info

|Item|Value|
|---|---|
|CPUs|Intel(R) Core(TM) i7-8086K CPU @ 4.00GHz (12 x 4008)|
|GPU Status|2d_canvas: enabled
checker_imaging: disabled_off
flash_3d: enabled
flash_stage3d: enabled
flash_stage3d_baseline: enabled
gpu_compositing: enabled
multiple_raster_threads: enabled_on
native_gpu_memory_buffers: disabled_software
rasterization: enabled
surface_synchronization: enabled_on
video_decode: enabled
webgl: enabled
webgl2: enabled|
|Memory (System)|15.93GB (9.90GB free)|
|Process Argv|C:\Users\yulin\Desktop|
|Screen Reader|no|
|VM|0%|

Extensions (1)

Extension|Author (truncated)|Version
---|---|---
vscode-language-pack-zh-hans|MS-|1.31.4

[KyleNanakdewa]

Getting this too after updating to 1.31.

VS Code seems to be showing as an HDR application, as the "SDR content appearance" slider in Windows HD Color Settings (which affects brightness of non-HDR apps) affects everything except VS Code.
Turning HDR off system-wide makes the window look normal again.

[SidShetye]

Same issue with 1.31 and VSCode is unusable. It's a lot worse on your eyes/mind than a camera can capture in the above photos.

Is there a VSCode/Electron workaround till this is resolved in a new release? Disabling system-wide HDR affect several other applications and workflows.

[SidShetye]

In the meantime, I recommend

• downgrading to November 2018 1.30.2 which doesn't have this issue AND
• disabling updates (gear icon in bottom left -> settings -> type "update" -> now in the left visible tree click Application -> Update -> Set Channel = none and uncheck "Enable Windows Background Updates". Now restart VSCode )

[KyleNanakdewa]

@SidShetye

Is there a VSCode/Electron workaround till this is resolved in a new release? Disabling system-wide HDR affect several other applications and workflows.

I haven't found any workarounds aside from downgrading VS Code back to 1.30.2 (download links are here).

You can download and run the installer, and it will do an in-place downgrade of VS Code, no need to uninstall or reconfigure settings. Just make sure to temporarily disable auto-update, as otherwise it will upgrade back to 1.31 every time you restart VS Code.

[eligrey]

Here's a non-HDR photo to partially convey the issue. It's hard to capture the actual darkness levels on my camera.

[Bara]

Or another workaround without downgrade: Set the compatibility mode to windows 7 of Code.exe (located in install directory), but with this change the Task/Build System doesn't work anymore - in my case.

[DuIslingr]

Or another workaround without downgrade: Set the compatibility mode to windows 7 of Code.exe (located in install directory), but with this change the Task/Build System doesn't work anymore - in my case.

I like this solution better than downgrading. +1 from me till issue is fixed

[AndreVanKammen]

I'm also having this same issue, I remember earlier versions of chrome having the same issue.

https://productforums.google.com/forum/#!topic/chrome/0d3YnxgmO9g;context-place=topicsearchin/chrome/category$3Areport-a-problem-and-get-troubleshooting-help%7Csort:relevance%7Cspell:false

https://www.reddit.com/r/chrome/comments/8jwz5q/the_chrome_is_too_dark_issue_is_a_result_of_hdr/

I thought it was finally time for a HDR desktop, maybe i'll just turn it off for now.

[AndreVanKammen]

Found a simple fix, just start Code with

Code --force-color-profile srgb

this makes it bright again

[zhuman]

Chromium upstream took a change a while back to read the SDR whitelevel since Chromium does its own FP16 composition. Electron needs to either always use a non-FP16 swap-chain or else do the HDR composition in FP16 properly and respect the user's SDR whitelevel setting.

[dylanh724]

Can confirm this still goes gray. Can also confirm that _workaround_ works.

[eggcar]

Any progress on this issue? Still too dark 1.34.0

[didaskein]

Same issue with HDR activated on Windows...

[Dragoon1010]

i have same problem

[melme12]

In the meantime, I recommend

* downgrading to [November 2018 1.30.2](https://update.code.visualstudio.com/1.30.2/win32-x64-user/stable) which doesn't have this issue **AND**

* disabling updates (gear icon in bottom left -> settings -> type "update" -> now in the left visible tree click Application -> Update -> Set Channel = none and uncheck "Enable Windows Background Updates". Now restart VSCode )

I have the same problem. This is the only workaround that helped me.

[sethRait]

@bpasero are there any updates on this? I've seen other electron apps fix this problem in the past 2 months.

[bpasero]

Can you try to reproduce with our nightly insider builds? You can give our preview releases a try from: https://code.visualstudio.com/insiders/

[sethRait]

Seems to be fixed in the insiders build. Any idea when this fix is coming to stable?

[bpasero]

Next week

[qhaque]

The insiders build that I downloaded today did NOT fix the dimming problem for me.

Using '--force-color-profile srgb' does work, though.

[bpasero]

As for being able to define force-color-profile srgb as a setting, please check: https://github.com/microsoft/vscode/issues/65816

[bpasero]

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/

[SidShetye]

@bpasero did you actually confirm this issue to be resolved? Because on 1.36 this is still an issue. Launching it with --force-color-profile srgb is proper (good color and contrast) while launching it without is still washed out. Windows 10 v1903, HDR slider to 60%, nVidia RTX 2070 latest drivers.

[WangZishi]

@bpasero Issue remain after upgrade 1.36. The window is too bright than normal(--force-color-profile srgb)

[bpasero]

Got it. Should have mention that this is a duplicate of https://github.com/microsoft/vscode/issues/65816 to make it configurable as a user setting.

[pl4yradam]

Still broken for me. This shouldn't be that difficult to resolve surely?

[taswyn]

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/

I've downloaded both Insiders (around when that post was made) and the 1.36.1: neither actually fixes HDR issues, in fact 1.36 made them markedly worse (it went from "quite bad" to "basically illegible"). The workaround of running VS Code with the switch --force-color-profile sRGB does at least work for me, and while having that be a configurable setting would help, I think it's more of an issue of needing the default(s) (whether changing the color profile or changing how it codes colors for a given profile) to be fixed so people aren't left having to hunt down an obscure setting in the first place: no other software I have has this issue with Windows 10 HDR, for what it's worth. I assume --force-color-profile srgb works fine on non HDR, so it's unclear why this is marked closed if the core issue isn't actually resolved without resorting to workarounds.

I've seen the other linked issue thread (65816) discussing wanting Code to respect the target color profile being the reason behind some of these changes, but it seems as if Code is only sending sRGB based color data either way, but improperly switching which color profile it claims to be working in to match whatever Windows is reporting when HDR is on, resulting in sending color data that's not properly re-mapped for the profile it's now claiming to use. Without knowing more/spending more time digging about Electron/Atom's render path this is me making a bunch of assumptions, but they seem to be the case.

For example, without forcing an sRGB profile, what happens is that black (#000000) is in fact a true black on my monitor, but white (#FFFFFF) is displayed as a dark gray (my hunch is that this probably matches to roughly #646464 if someone's "Brightness for SDR content" slider is all the way to the right... in fact, mine is a bit to the left and the two are very close to matching, see the attached photo

), and all other colors are falling between the two of them. This is what might be expected of an application that claims to be displaying in a wide gamut color space but is only sending standard gamut color information. I'm not entirely clear on how the newer Windows 10 HDR desktop mechanism works in terms of color profiles returned via whichever API (DWM?) is being used to query and set them, I haven't done any desktop Windows dev work in years, but it seems like whatever trick allows Windows to forcibly remap (with a gamma slider) sRGB applications to an HDR display is being negated by querying the color profile and automatically switching to it: therefor if that's going to happen, the application needs to be capable of sending wide color gamut information back to the render process, instead of standard color gamut information despite claiming a wide color gamut profile (what seems to be happening now with VS Code). To someone who totally admits she doesn't know as much about exactly how this is working as she'd like, it seems like if there's not a map for a given color profile/gamut width available, VS Code should be falling back automatically to signaling itself as an sRGB profile.

[MarkIngramUK]

The fix is relatively straight forward, query for DISPLAYCONFIG_SDR_WHITE_LEVEL and then multiply colours by DISPLAYCONFIG_SDR_WHITE_LEVEL.SDRWhiteLevel / 1000.0f (in linear gamma space).

[eligrey]

@MarkIngramUK Would you be able to take the time to submit a PR with this fix?

[MarkIngramUK]

@eligrey , unfortunately I've never looked at the source for VSCode (or Electron), so wouldn't know where to start. I just know the Windows API call to make...

[abl]

I noticed this issue today before and after updating - sorry, didn't think to check the previous version - and I'm now on 1.36.1.

I have two displays attached - one is HDR capable, the other is not - and HDR is off globally. I was noticing the issue on my non-HDR monitor.

I removed all extensions, uninstalled and reinstalled, and the issue persisted. Starting with --force-color-profile srgb resolved it for me.

[MarkIngramUK]

I've just updated to 1.36.1 and it's now far too bright when the SDR content appearance slider is set to minimum (in Windows HD Color Settings). When the slider is at minimum, there should be no brightness adjustment for SDR content (the multiplier is 1x).

[ta32]

@bpasero i still have the issue in vscode 1.37 can you re-open this issue please

[bpasero]

@ta32 I wonder if your issue is different and is fixed by using Electron 6, can you try that?

Download:

• macOS: Download
• Linux (DEB): Download
• Linux (RPM): Download
• Windows: Download

[ta32]

hi @bpasero the exploration version with electron 6 works

[SidShetye]

Continues to be broken even in 1.37.1 but appears to be fixed in 1.37.0-exploration.

@bpasero when or what mainline release of VSCode will pick up this fix?

[exzizt]

Same here. Latest version.

[burianvlastimil]

Laptop display: non-HDR 3840x2160
External display: HDR 3840x2160

Windows version:

Actual result (photo):

Is this applicable to this issue? The VS Code window is dim only when the external display is attached (no matter on which display Code is placed then).

Workaround mentioned above works.

--force-color-profile srgb

[MarkIngramUK]

@burianvlastimil yes mine appears the same as that.

[jason-lizarraga]

I've also had this issue for months. Every release I go to the shortcut and add "--force-color-profile srgb".

[ProfessorStrawberry]

i installed insiders version for now, because the problem does not seem to get fixed

or can we expect electron 6 for the normal release soon?

[mbround18]

I am experiencing the same issue looking for a fix please

[antoniocgj]

It seems VSCode stopped accepting the "--force-color-profile srgb" option. Any ideas on how to solve this problem now?

[deepak1556]

Fixed with https://github.com/microsoft/vscode/pull/81644