[OOBE] Resizing of window (at opening) results in unwanted effects

[Jay-o-Way]

Microsoft PowerToys version

0.35.0

Running as admin

No

Area(s) with issue?

General

Other Software

No response

Steps to reproduce

• Open the Settings window
• Click the "Welcome to PowerToys" link
• Look closely at the nNavigation

✔️ Expected Behavior

None or normal animation

❌ Actual Behavior

There's an animation at the moment the window is opened, but it only applies to Seven of Nine navigation items. First two are stationary.

Also notice the incorrect display of the contents, the very first time.

2021-04-05.18-19-20.mp4

[Jay-o-Way]

Very rare:

[htcfreek]

Very rare:

That's strange. We had a bug on this while in pr state. But this should be fixed.

Can you add some details on you monitor setup for investigation, please.

cc: @niels9001

[Jay-o-Way]

The monitor setup is very standard, 1920x1080 @ 100%. It happened the very fist time while recording, and once later after clicking the link again and again. But like I said: it's rare :)

[htcfreek]

The monitor setup is very standard, 1920x1080 @ 100%. It happened the very fist time while recording, and once later after clicking the link again and again. But like I said: it's rare :)

For me it's looks like a xaml/winui problem on your system. 🤷

[Jay-o-Way]

I'm guessing it (the width) has to do with the logic that happens when the window is called for. There are functions like

"window.width=0"
"window.height=0"
"fit into window"
"move to center"

(with the idea to remove flickering) and they all "shake the window around" and the contents just has have to deal with it. Every single time. I suggest to remove some of these weird things.

[htcfreek]

I'm guessing it (the width) has to do with the logic that happens when the window is called for. There are functions like

"window.width=0"
"window.height=0"
"fit into window"
"move to center"

(with the idea to remove flickering) and they all "shake the window around" and the contents just has have to deal with it. I suggest to remove some of these weird things.

The move to center must be there to avoid incorrect placing. (Don't know the issue number at the moment.)

[Jay-o-Way]

#10022

        public static void ShowHide(Window window)
        {
            // To limit the visual flickering, show the window with a size of 0,0
            // and don't show it in the taskbar
            var originalHeight = window.Height;
            var originalWidth = window.Width;
            var originalMinHeight = window.MinHeight;
            var originalMinWidth = window.MinWidth;

            window.MinHeight = 0;
            window.MinWidth = 0;
            window.Height = 0;
            window.Width = 0;
            window.ShowInTaskbar = false;

            window.Show();
            window.Hide();

            window.Height = originalHeight;
            window.Width = originalWidth;
            window.MinHeight = originalMinHeight;
            window.MinWidth = originalMinWidth;
            window.ShowInTaskbar = true;
        }

It's overkill. Just use WindowStartupLocation="CenterScreen" or something.

[crutkas]

This could totally be an artifact of XAML Islands / NavView WinUI 2.x. I've never seen it so I'd defer to just the migration then for WinUI 3 rather than fix it here.

After the recalc, it is rendered correctly so i'd put this as a low pri item and there is no clear repro and have the actual fix be the port in #6715

[Jay-o-Way]

@crutkas Freek and I have been going back and forth about the (rare) visual width bug, but what about the animation that does not get applied to the first two items??

[crutkas]

I've noticed the animation quirk as well but that very well could also be a quirk of Islands. Settings actually has a similar keyboard focus quirk for items 3 and lower. Looking at the code nothing screamed smoking gun for cause. Knowing in a few months all this code will go a lift and shift to WinUI3, not something i feel we need to spend time on since they do actual quickly render correctly.

[htcfreek]

@Jay-o-Way, @crutkas
I would like to mention that my name is neither htc nor freek. (htcfreek is a fantasy name made from letters of my name and a misspelled german word.) 😂 You can use htcfreek or Heiko.

@Jay-o-Way
I think this is a xaml bug. The animation is xaml driven and not initiated or manipulated by our code.

[niels9001]

@Jay-o-Way Only OOBE suffers from this while we made no UI related changes to the default WinUI controls. I wasn't able to reproduce it on my machine.

I agree with @crutkas that this is probably one of the many visual bugs caused by XAML Islands. (The same code running in UWP does not have these bugs).

Once we adopt WinUI 3 these bugs are hopefully gone, if not let's revisit this issue then :).

[Jay-o-Way]

I would like to mention that my name is neither htc nor freek. (htcfreek is a fantasy name made from letters of my name and a misspelled german word.) 😂 You can use htcfreek or Heiko.

My apologies. Freek is a plausible name, but I was indeed assuming, since your full name doesn't show next to your screen name :)

For the rest: alright then. 🤐

[htcfreek]

I would like to mention that my name is neither htc nor freek. (htcfreek is a fantasy name made from letters of my name and a misspelled german word.) 😂 You can use htcfreek or Heiko.

My apologies. Freek is a plausible name, but I was indeed assuming, since your full name doesn't show next to your screen name :)

Added my first name to the profile now. 😂

Freek (correctly: Freak) is someone that is really good in something and invests much time in that thing. In my situation: Computers 😅

[Jay-o-Way]

@niels9001 @crutkas @htcfreek Late insight 💡 I now realize the two things (width & 'animation') are a (unwanted and relatively slow) result of the immediate resizing - first to width & height of zero and back to normal. So, not a xaml bug, but a result of human programming.