Must the window be white before it's painted?

[vefatica]

Description of the new feature/enhancement

Let the user pick the color of the window before it's painted.

Here when I start WindowsTerminal, it flashes completely bright white before it's painted black. It's only a split second, but it's very annoying.

Proposed technical implementation details (optional)

I wrote a crude GUI app (not my forte) to play with this. I found that I could control the initial background color of the window by setting WNDCLASS::hbrBackground before registering the class. I used the canned (HBRUSH) COLOR_WINDOWTEXT which happened to be black. I suppose I could have created my own HBRUSH.

I'd like the window not to be conspicuously COLOR_A (white here) when it's first shown, only to become COLOR_B (black here) a split second later. If there were a global setting in WindowsTerminal, you might make lots of folks happy.

Many apps exhibit this behavior. I looked and googled for a while and couldn't find a Windows setting for the default color of a newly-shown window. White is what you get when you use wc.hbrBackground = nullptr. Does anyone know if I change this color system-wide?

• Vince

[mdtauk]

Ideally this plain window colour would match the chosen theme, so light grey for Light Theme, and dark grey for Dark Theme.

[DHowett]

Ideally this plain window colour would match the chosen theme, so light grey for Light Theme, and dark grey for Dark Theme.

This is the problem actually 😄

The plain window color matches the OS theme. It's bright when the OS is set to be bright, and it's dark when the OS is set to be dark.

Since it's only meant to be seen for a few milliseconds, we should probably set it to be the active background color of the first-launched profile.

[vefatica]

If this is what you mean, I'm already at dark.

Most apps show a white window momentarily. Office apps don't.

[mdtauk]

Ideally this plain window colour would match the chosen theme, so light grey for Light Theme, and dark grey for Dark Theme.

This is the problem actually 😄

The plain window color matches the OS theme. It's bright when the OS is set to be bright, and it's dark when the OS is set to be dark.

Since it's only meant to be seen for a few milliseconds, we should probably set it to be the active background color of the first-launched profile.

I guess you can't read the chosen theme from the settings before the Window starts to paint?

[DHowett]

Nah, we actually have to load the settings so that we may size the window properly. Ideally we would paint the top in the theme color and the bottom in terminal color before everything loads, to make it a little more ~ ~ seamless ~ ~.

[vefatica]

I'm talking about what happens before WT does any painting, i.e., at ShowWindow time. If hbrBackground is specified in the registered WNDCLASS struct, it'll be used when you use ShowWindow. You can always get rid of it, later, with SetClassLongPtr and GCLP_HBR_BACKGROUND ... even make it NULL. Are we on the same wavelength?

[DHowett]

I'm talking about what happens before WT does any painting, ... Are we on the same wavelength?

Yes, we are.

[zadjii-msft]

Oh my gosh, this is already on the backlog. Look at that.

/dup #5572

[ghost]

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!