Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Starting WT momentarily shows a black titlebar #11561

Closed
rashil2000 opened this issue Oct 21, 2021 · 10 comments · Fixed by #12979 or #13811
Closed

Starting WT momentarily shows a black titlebar #11561

rashil2000 opened this issue Oct 21, 2021 · 10 comments · Fixed by #12979 or #13811
Labels
Area-User Interface Issues pertaining to the user interface of the Console or Terminal Area-Windowing Window frame, quake mode, tearout Help Wanted We encourage anyone to jump in on these. In-PR This issue has a related PR Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Tag-Fix Doesn't match tag requirements Priority-3 A description (P3) Product-Terminal The new Windows Terminal. zPreview-Service-Queued-1.13 A floating label that tracks the current Preview version for servicing purposes.
Milestone
Terminal v1.18

Comments

@rashil2000
Copy link
Contributor

Windows Terminal version (or Windows build number)

10.0.19043.1288 1.12.2922.0

Other Software

No response

Steps to reproduce

Start WT.

Expected Behavior

The GUI should start without showing a glitched black title bar, just as it did in v1.11.

Actual Behavior

It shows a black title bar for a few milliseconds. See below:

2

1

My settings.json is the same as before I upgraded (through Store).
@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Oct 21, 2021
@zadjii-msft
Copy link
Member

showerthought: we could have a solid BG for the TerminalPage until initialization is completed, and then drop out the bg. That might obscure the titlebar until the rest of the content initializes.

@zadjii-msft zadjii-msft added Area-User Interface Issues pertaining to the user interface of the Console or Terminal Area-Windowing Window frame, quake mode, tearout Help Wanted We encourage anyone to jump in on these. Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-3 A description (P3) Product-Terminal The new Windows Terminal. labels Oct 21, 2021
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label Oct 21, 2021
@zadjii-msft zadjii-msft added this to the Terminal v2.0 milestone Oct 21, 2021
@zadjii-msft zadjii-msft added the zPreview-Service-Queued-1.13 A floating label that tracks the current Preview version for servicing purposes. label Oct 21, 2021
@zadjii-msft
Copy link
Member

zadjii-msft commented Oct 25, 2021 •
edited
Loading

Note to self - that didn't work. Might need to do this higher up in Win32 land. Might need to actually start with the window painted with some color, then paint it all with BLACK_BRUSH

You also can't just hack this by immediately creating the window without WS_EX_NOREDIRECTIONBITMAP and then later turning that style on. You have to create the window with WS_EX_NOREDIRECTIONBITMAP, SetWindowLong won't work.
see:

@Rosefield
Copy link
Contributor

This was something that I noticed with the upgrade to WinUI 2.7, in case that gives any help.

@DHowett
Copy link
Member

DHowett commented Oct 25, 2021

I suspect that this is more due to the changes we made to drop out the back of the window in #11180

@zadjii-msft
Copy link
Member

Yea, this was definitely regressed in #11180. I've spent enough time on this for this week, but made no real progress. I don't think we can just draw the BG manually in WM_ERASEBKGND or something, because there is not GDI redirection surface to draw to. my current crazy idea is using CreateSwapChainForHwnd to create a swapchain for the hwnd, draw the color to that, then make it transparent once the Island is initialized. Not sure I have time to futz with that now though. DirectComposition might be an easier way, but this tutorial looks... long and maybe more complicated than we need. maybe next DoL.

What we really need is someone who actually understands user32 to come give us an assist on this one.

zadjii-msft added a commit that referenced this issue Oct 28, 2021
@zadjii-msft
A bunch of dead ends for #11561
b729444
@zadjii-msft
Copy link
Member

Some gifs recorded this morning of the issue. No progress to report.

transparent-frame-on-launch-000
transparent-frame-resizing-000

@zadjii-msft zadjii-msft mentioned this issue Dec 9, 2021
Closed
@zadjii-msft zadjii-msft modified the milestones: Terminal v2.0, 22H2 Jan 4, 2022
This was referenced Feb 2, 2022
Open
Open
@zadjii-msft zadjii-msft removed the Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting label Feb 17, 2022
@zadjii-msft zadjii-msft mentioned this issue Apr 18, 2022
Closed
@zadjii-msft
Copy link
Member

Note to self: maybe we can DWM_CLOAK the window until it's initialized

@antcodd antcodd mentioned this issue Apr 20, 2022
Closed
zadjii-msft added a commit that referenced this issue Apr 20, 2022
@zadjii-msft
This fixes #11561
0fc4bdc 
Cloak the window until XAML is ready to go
@zadjii-msft
Copy link
Member

note to self: tried just setting a BG for the TerminalPage then yanking that after we're initialized. There's still a few frames before the XAML content loads at all. I'd say the cloaking thing felt more polished comparatively.

@zadjii-msft zadjii-msft mentioned this issue Apr 25, 2022
Merged
4 tasks
@ghost ghost added the In-PR This issue has a related PR label Apr 25, 2022
@ghost ghost closed this as completed in #12979 May 6, 2022
@ghost ghost removed the In-PR This issue has a related PR label May 6, 2022
ghost pushed a commit that referenced this issue May 6, 2022
@zadjii-msft
Hide the window from DWM until we're finished with initialization (#1…
14098d7 
…2979)

When we start up, our window is initially just a frame with a transparent content area. We're gonna do all this startup init on the UI thread, so the UI won't actually paint till it's all done. This results in a few frames where the frame is visible, before the page paints for the first time, before any tabs appears, etc. 

To mitigate this, we're gonna wait for the UI thread to finish everything it's gotta do for the initial init, and _then_ fire our Initialized event. By waiting for everything else to finish (`CoreDispatcherPriority::Low`), we let all the tabs and panes actually get created. In the window layer, we're gonna ~cloak~ just not show the window till this event is fired, so we don't actually see this frame until we're actually all ready to go. **This will result in the window seemingly not loading as fast**, but it will actually take exactly the same amount of time before it's usable. 

I also experimented with drawing a solid BG color before the initialization is finished. However, there are still a few frames after the frame is displayed before the XAML content first draws, so that didn't actually resolve any issues.

* [x] Closes #11561
* [x] Tested manually
* [x] I work here.
* [x] Accidentally also closes #9053. By switching the initial call from `ShowWindow(SW_SHOW)` to `ShowWindow(SW_SHOWDEFAULT)`, we actually obey the startup info now.
@ghost ghost added the Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. label May 6, 2022
carlos-zamora pushed a commit that referenced this issue May 6, 2022
@zadjii-msft @carlos-zamora
Hide the window from DWM until we're finished with initialization (#1…
deb0df6 
…2979)

When we start up, our window is initially just a frame with a transparent content area. We're gonna do all this startup init on the UI thread, so the UI won't actually paint till it's all done. This results in a few frames where the frame is visible, before the page paints for the first time, before any tabs appears, etc.

To mitigate this, we're gonna wait for the UI thread to finish everything it's gotta do for the initial init, and _then_ fire our Initialized event. By waiting for everything else to finish (`CoreDispatcherPriority::Low`), we let all the tabs and panes actually get created. In the window layer, we're gonna ~cloak~ just not show the window till this event is fired, so we don't actually see this frame until we're actually all ready to go. **This will result in the window seemingly not loading as fast**, but it will actually take exactly the same amount of time before it's usable.

I also experimented with drawing a solid BG color before the initialization is finished. However, there are still a few frames after the frame is displayed before the XAML content first draws, so that didn't actually resolve any issues.

* [x] Closes #11561
* [x] Tested manually
* [x] I work here.
* [x] Accidentally also closes #9053. By switching the initial call from `ShowWindow(SW_SHOW)` to `ShowWindow(SW_SHOWDEFAULT)`, we actually obey the startup info now.

(cherry picked from commit 14098d7)
Service-Card-Id: 81599073
Service-Version: 1.14
@zadjii-msft
Copy link
Member

Whoops, we reverted this and never reopened

@zadjii-msft zadjii-msft reopened this Jul 25, 2022
@zadjii-msft zadjii-msft mentioned this issue Jul 25, 2022
Closed
@zadjii-msft zadjii-msft mentioned this issue Aug 22, 2022
Merged
@ghost ghost added In-PR This issue has a related PR and removed Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. labels Aug 22, 2022
@zadjii-msft
Copy link
Member

From teams:

This is the "empty terminal" animating in thing I mentioned

you likely want to hookup a solid color brush via DComp/WinComp that paints everything some opaque color to avoid this

your swapchain effectively "does not exist" until the first present is finished so this is why you get this behavior

@zadjii-msft zadjii-msft modified the milestones: 22H2, Terminal v1.17 Sep 2, 2022
@zadjii-msft zadjii-msft mentioned this issue Nov 28, 2022
Closed
zadjii-msft added a commit that referenced this issue Apr 6, 2023
@zadjii-msft
Revert the revert of "Hide the window until we're finished with initi…
083fc64 
…alization" (#13811)

This is a revert of the revert of #12979. We mainly reverted that PR
because of an issue where restored windows would grow/shrink slightly on
external displays. It was too close to the ship date for that release,
so we backed it out wholesale (in #13098). I think I've found the real
root of the problem, and fixed it here.

The money diff here from the original PR:
4c08b9a...c34495d.
Basically, I had put the part where we actually handle the creation of
the window into `_AppInitializedHandler`, when we should have left the
window to be created in `_HandleCreateWindow` We create it there,
_hidden_, and then should only _show_ it in `_AppInitializedHandler`.

I'm _NOT_ incorporating the change for #9053. I reverted that bit in
1fac403. I am too worried about that messing with the phwnd that I
wanted to get that reviewed and committed atomically, separately.

* fixes  #11561
* tested manually
* I work here
@microsoft-github-policy-service microsoft-github-policy-service bot added the Needs-Tag-Fix Doesn't match tag requirements label Apr 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Area-User Interface Issues pertaining to the user interface of the Console or Terminal Area-Windowing Window frame, quake mode, tearout Help Wanted We encourage anyone to jump in on these. In-PR This issue has a related PR Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Tag-Fix Doesn't match tag requirements Priority-3 A description (P3) Product-Terminal The new Windows Terminal. zPreview-Service-Queued-1.13 A floating label that tracks the current Preview version for servicing purposes.
Projects
None yet
Milestone
Terminal v1.18
4 participants
@DHowett @Rosefield @zadjii-msft @rashil2000