Proposal: Click on cascading menu items to instantly open the cascading menu

[Poopooracoocoo]

Proposal: We should be able to click on cascading menu items to instantly open the cascading menu

Summary

We should be able to click on cascading menu items to instantly open the cascading menu.

Rationale

• Consistency with win32 menus
• It makes things faster and feel faster

Scope

Capability	Priority
Users can click on an item in a MenuFlyout that reveals another menu instantly	Must

Important Notes

The animation makes menus feel slow. This is something to consider but is worth its own issue.

[YuliKl]

@Poopooracoocoo, I don't think I'm understanding the proposal. Can you point me to a specific example of an app whose experience will be improved by making this change?

[jevansaks]

There's a small (but noticeable) delay between when you hover over a parent menu item. In Win32 menus if you click the menu would open immediately, in XAML it doesn't.

I agree we should do this for consistency. Should be a pretty straightforward change once we're able to make changes in WinUI 3.0.

[jevansaks]

I filed this as a feature request instead of a bug even though I thought of it as something that was overlooked and therefore a bug.

No worries! It's borderline for me too, but since there's very strong prior art in this area I think it's easy to follow suit.

[github-actions]

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[fredemmott]

This feels beyond 'slow' in Windows App SDK v1.4.2, including in the WinUI3 gallery; it is taking 2-3 seconds of hover to open with no visual feedback, so I thought cascading menus were completely broken.

Can be reproduced with the 'cascading menus' example on the menu flyouts page of WinUI3 gallery.

[kmgallahan]

@fredemmott I see no 2-3 second delay. In fact, the menu opens so quickly on hover that I don't think I can even click before the animation has finished.

Do you have another machine to test on?

[fredemmott]

@fredemmott I see no 2-3 second delay. In fact, the menu opens so quickly on hover that I don't think I can even click before the animation has finished.

Do you have another machine to test on?

I'm seeing this on two machines with Windows 10, z790, 13900k, and RTX4090
I am not seeing it (the flyout opens quickly) on a machine with the same version of windows 10, z370, 8700k, and RTX4070

All 3 machines are running Win 10 22H2 1904.3693 with all windows updates, and the 546.17 nvidia driver

[kmgallahan]

I think this might be related to:

microsoft/terminal#14756

microsoft/terminal#15545

@ranjeshj because I don't know who else to mention regarding how to further investigate this.

[fredemmott]

From reading those comments, I tried turning "Show Animations in Windows" off in the windows control panel (screenshot) - interestingly, this reliably makes things worse: 5-6 seconds. Turning it back on gets me back to 2-3 seconds.

[kmgallahan]

Unless/until someone from Microsoft recommends a better way, my typical approach to diagnosing different behaviors on different machines is to try to find differences and eliminate them one at a time. Painful, but sometimes gets it done.

Maybe check monitor setup including resolution, display scaling, text scaling. Kill all 3rd party programs, in particular anything that uses drivers or monitors other running software (antivirus, work activity monitoring, Grammarly, etc.).

For reference, I'm on W10 with a 2700K and GTX 580 (lul).

[fredemmott]

This appears to be a problem with high refresh rates:

slow machines:

• 100% scaling, 1080p 240hz gsync on, windows Variable Refresh Rate off
  • disabling g-sync: no change
  • enabling windows VRR: no change
  • reducing from 240hz to 60hz: FIXED, regardless of VRR or gsync settings
• 150% scaling, 5120x1440 240hz gsync on, windows VRR off
  • disabling g-sync: no change
  • enabling windows VRR: no change
  • reducing from 240hz to 60hz: FIXED, regardless of VRR or gsync settings

Fast machine:

• 150% scaling, 3x 4K 60hz fixed

All:

• Hardware assisted GPU scheduling off
• No third-party software or AV, no monitoring, no third-party background services other than essential drivers and 1password

With my limited options (screenshot):

• very fast (a small fraction of a second) at up to and including 143.981hz
• multiple seconds as soon as I switch to 200hz or above

[jeremy-visionaid]

@fredemmott Nice catch with the refresh rate. I agree with the other comments here - it's so laggy at 2-3 seconds that you think it's broken. Setting my screen refresh rate to 60 Hz makes the pop up much faster.

[gegao18]

@fredemmott Nice find! Yes, there is an issue with variable refresh rate displays and how WinUI 3 keeps track of time that causes multi-second delays in DispatcherTimers firing. This is tracked by #9371, and we have a fix coming in 1.5.2. This issue (and #8921) tracks the slight delay in opening nested menus with a mouse click, and this delay exists regardless of the type of device running the app.

[fredemmott]

@gegao18 to be clear, this is at high refresh rates - enabling/disabling variable refresh rate does no difference

[bkudiess]

This was fixed internally and will be available in WASDK 1.7