Window size is not calculated correctly on startup and there are two window frames

[YanceyChiew]

I noticed that recent commits brought a new behavior on window startup. (no earlier than May 3)

Previously, a blank frame is displayed first when the window is opened, leaving the client area of ​​the shell transparent for a while. And now, this area is no longer transparent, but has a inborn window background, which is great.

But the problem is that the background doesn't directly fill the transparent area left by the window frame, but has a strange initial value 110 * 22(related to the font size, the current value corresponds to the default font size of 12), the rest area remains transparent, and then fills the rest area in a subsequent resizing.

This initial value is neither the same as the current value nor default value of the Launch Size in the Startup settings. Here are some specific behaviors:

• If the Launch Size is 110 * 22 and Font Size is 12, you will not see the resize process.
• If the number of Columns is less than 110, the three buttons in the upper right corner will appear outside the visible window at first, and then move inside the window after resize.
• If the Launch Size is greater than 110 * 22, two window frames of different sizes will overlap when the window is initialized. They have different theme colors and own three buttons in the upper right corner.
• If only the number of Rows exceeds 22, although it stands to reason that the number of Columns does not change during the resize process, the reality is the three buttons in the upper right corner will have a subtle scaling effect.
• If you increase the Font Size without changing the Launch Size correctly, the outermost window will become larger and create a new gap. Conversely, reducing the Font Size will cause the three buttons in the upper right corner to move to the left from outside the visible window.

It is not difficult to see from the above mentioned behaviors that the reason for the gap in the background is that the window size, which was calculated by the Font Size and the Launch Size, was given different results by window showing and it‘s subsequent resizing.

It may not be difficult to make the calculation correct, what I'm really trying to say is whether it's possible to strip the resize step during starting up window, although it plays a positive role in the behavior mentioned in this post, but if the size is already calculated correctly when the window is initialized, there is obviously no need for unconditional resize.

Also, the two overlapping window frames are very concerning.

[zadjii-msft]

Uh, can you possibly post a screen recording? ScreenToGif is particularly useful for this. If a picture is worth a thousand words, then a recording is worth 24000 words per second 😄

I'm mildly worried that #12979 may have caused this

[YanceyChiew]

screen-capture.webm.mp4

[zadjii-msft]

Thanks for the video! That really helps illustrate.

Huh. It's like, the XAML island isn't being resized to the right size right away. This combo'd with what I'm seeing in #13066 - we may need to back out the DWM hide thing.

@DHowett as an FYI. If I was here the rest of the week, maybe I could sort this out. I'm guessing I won't find a root cause before I tap out. Backing it out is the safest ripchord, and would be a lot simpler for merging just dda1102, without having to worry about the flashing.