Terminal: Terminal has white borders in dark mode (Update ThemeUtils::SetWindowFrameDarkMode to use new DWM API)

[greg904]

From #3394:

I'd be most comfortable merging this without the dark theme fix (which I know will cause there to be white borders around the entire window instead of just at the bottom) and then bringing in the dark theme changes when the other fix has flowed back down from Windows.

[DHowett-MSFT]

Finally figured this out!

If we set the extended frame margins to {0}, we can fully suppress the white border. The cost, though, is that we have to paint our own accent color -- but only on the _top_ of the window. The borders stay the same.

Accent On

Accent Off

Notice how the right border _is visible_, just dim. This looks like Chrome and Firefox as well.

[greg904]

Maybe one way is to use DwmGetColorizationColor and WM_DWMCOLORIZATIONCOLORCHANGED to get the accent color and HKCU\Software\Microsoft\Windows\DWM\ColorPrevalence to detect if we need to put the accent color in the title bar or not. Last time I tried, watching for registry changes for this key didn't work in the app but worked in another Win32 project (so maybe because it's a store app? I don't really know how this works) so I couldn't make it update when you change the setting at runtime. So I abandoned this idea to draw the top border ourselves but looking back I think that it's not a big deal.

Also, note that the border's color is a little bit brighter than the title bar's color so the value from DwmGetColorizationColor needs to be modified. You can see a 1px border with lighter color than the title bar if you zoom in this screenshot and you look at the top and left of the window:

[DHowett-MSFT]

@greg904 we probably need _both_ actually -- to listen to WM_DWMCOLORIZATIONCOLORCHANGED _and_ to read ColorPrevalence. We shouldn't need to listen to the registry key directly, since it _should_ be wrapped up in the WM.... Chromium seems to have an algorithm for figuring out the accent border color; perhaps there's something we can learn from it?

[greg904]

I would assume that WM_DWMCOLORIZATIONCOLORCHANGED is only sent when the accent changes (DwmGetColorizationColor) but not when the accent color on title bar and borders setting (ColorPrevalence) is toggled based on the name. But I need to check this. EDIT: I was wrong, it's also sent when that setting changes.

I found this from Chromium: https://github.com/chromium/chromium/blob/af5c81b48faf773c19b7f3c495a1c0202f9c5b00/chrome/browser/themes/theme_service_win.cc#L60
https://github.com/chromium/chromium/blob/af5c81b48faf773c19b7f3c495a1c0202f9c5b00/chrome/browser/ui/views/frame/glass_browser_frame_view.cc#L609

Note that the algorithm that Chromium uses isn't working correctly in 1809+ when ColorPrevalence is disabled: https://bugs.chromium.org/p/chromium/issues/detail?id=950362.

The top border has the accent color but it should not, it should be gray like the other left, right and bottom borders:

[duke7553]

Not to get too off-topic here, but whichever method Microsoft Edge uses to draw the top border has the unintended consequence of mis-matching a transparent top border with the other 3 sides. This is visible only when the Windows theme is set to "dark" while the app theme is "light."

[Stanzilla]

@DHowett-MSFT is a fix for this coming in the next release?

[Piroro-hs]

The terminal still shows a 1 pixel thin white border on the left of unfocused window in some cases. In my case, the border only appears when the screen scale is 125% and disappears after window resizing.

just after launch

resized

Windows 10 18362.535
Windows Terminal 0.7.3451.0

[DHowett-MSFT]

@Stanzilla a fix will be coming for this bug in the release that comes after the bug is closed :smile:

[gwojan]

One thing I've just noticed is the white border is much more prominent on laptops with NVIDIA video adapters. I have three different Dell laptops and the one with AMD graphics the border is not nearly as noticeable. Does that make any sense at all?

All three laptops have Dark Mode enabled with Windows 10 1903.

[spencerwooo]

Can confirm on what @gwojan and @Piroro-hs reported. ThinkPad T460s with NVIDIA GeForce 930M on Windows 10 Pro 19041.21 with Windows Terminal (Preview) 0.8.10261.0. Screen resolution is 1920*1080 and the scale is set to 125%.

|State|Screenshot|
|:--:|:--:|
|Just After Launch (in focus)||
|Just After Launch (out of focus)||
|After resize (in focus)||
|After resize (out of focus)||

The left side white border is much more prominent than the other three when initially launched. After resizing the problem is gone.

[greg904]

This issue should probably be split into two issues:

1. Terminal has white borders in dark mode
2. Update ThemeUtils::SetWindowFrameDarkMode to use new DWM API

Because _2_ is one of many solutions to _1_ but it's not the only solution. For instance, https://github.com/microsoft/terminal/issues/3425#issuecomment-558943616 is another solution.

[greg904]

The more that I think about it, the more I wonder if it is possible that one of the devs who work at Microsoft can ask the people working on DWM (because it's also from Microsoft) why calling DwmExtendFrameIntoClientArea gives us a white border and how we can prevent it to fix this?

Since the beginning, I have been trying a lot of different weird workarounds to patch this because I have no idea how it works and I really want it fixed because it burns my eyes :) but nothing is really good. However maybe the people working on DWM could find a really simple fix in a few seconds because they know what's happening under the hood?

I used a program to see what API calls the ApplicationFrameHost.exe executable (which I think is the thing that manages UWP apps' windows) makes and it _does_ call DwmExtendFrameIntoClientArea with parameters { 0, 0, 32, 0 } but it doesn't have that weird white border so I'm missing something.

[DHowett-MSFT]

@greg904 you're totally right. The main issue is, though, that we want to ship something that'll work properly (or quasi-properly) all the way back to 19H1 (build 18362), and any solution we get from the DWM team is going to have a very long lead time.

I've been around the block with them a few times about what we "should" be doing to be good platform citizens but also blend in with other applications on the system. :smile:

I wouldn't be upset about a solution that calls DwmExtendFrameIntoClientArea(hwnd, {0}) and paints the top of the window -- Chromium (and therefore Edge) does it and Firefox does it. There's some downsides to doing it this way, but I would accept minor downsides for the visual improvement we'd get.

[DHowett-MSFT]

@greg904 (be careful investigating ApplicationFrameHost -- windows for modern applications get a little bit of special treatment, and they're actually slightly different in win32k, so we can't derive _too_ much info from looking at how they work.)

[DHowett-MSFT]

Alright, so here's the deal. I got agreement from the DWM team to ship an interim solution while they work to resolve the issue for Windows vNext. This interim solution comes in the form of a single DLL consumed through a NuGet package.

It's not amazing from the perspective of an open-source project, and I understand that. I'm happy to answer any questions.

[andrew-boyarshin]

@DHowett-MSFT it's great to see collaboration with DWM team!
It is, however, disappointing to see the solution to the issue being private and non-opensource. I imagine this is due to it using private DWM API such as window attributes №19-20 and UXTHEME ShouldAppsUseDarkMode method resolved by ordinal. It appears DWM team doesn't want to widen the API surface, make these official. I hope Windows Composition team will consider sharing more (maybe non-documented, without examples, but at least headers and/or LIB files) to enable advanced 3rd party developers, those who understand the responsibility of using non-documented APIs, to solve the issues they face.

[DHowett-MSFT]

@andrew-boyarshin _watch this space_ :smile:

I think us using UXTHEME isn't entirely required; DWM likely does this for us, but we were following somebody else's example.

We'll get it all ironed out in the end.

[michalhudecek]

Why is the issue closed? The part about white border when the terminal window is focused is not fixed. I have _accent color for title bars and window borders_ turned off. I cannot find an issue for that in GitHub

[DHowett]

Light system theme, light terminal theme, light borders.

[michalhudecek]

But they are usually black. See Windows Settings screenshot

[michalhudecek]

Or Edge

[michalhudecek]

Some more examples - all Microsoft apps!

[DHowett]

Your point is made.

[DHowett]

However, to answer your question:

Why is the issue closed?

Because this is the issue for terminal has white borders in dark mode, which is 100% fixed.

If you want to discuss changing the default for light mode, please file a separate issue :smile:

[michalhudecek]

There are many similar issues but they were closed too. It's true that some of them are only about dark mode but some of them are about white borders in general, eg. https://github.com/microsoft/terminal/issues/4837