Repeatedly updating explicit `Width` property causes frame drops about microsoft-ui-xaml HOT 4 OPEN

Can you share a video of what you're seeing? If layout is complex and takes a long time, then running layout at a high frame rate will be problematic. It might be necessary to do a visual-only update to represent how the layout sizes will change and limit the layout update until the end or at a much lower frequency, for example. Layout is not intended to run at 30 fps in general.

from microsoft-ui-xaml.

@codendone Yeah I'll see if I can reduce this and post a video. I don't necessarily expect layout to run at 30fps (it's gonna take as long as it takes), but the behavior I'm observing is that if I'm issuing size updates at ~30 fps then I can get into a state where frames stop getting drawn to screen entirely, for multiple seconds, until I stop issuing the size updates. So what I'm looking for is either:

• Changes to the layout system that would ensure intermediate layouts are getting drawn to screen even if the size gets updated and triggers another layout pass quickly, or
• A reliable signal for 'the layout pass completed and has drawn a frame to screen' so that I can implement the necessary throttling myself rather than relying on timing-based heuristics. It appears that SizeChanged fires too early to be usable for these purposes; that is, even if I ensure that I only issue size updates as quickly as SizeChanged events are coming in, it's still possible for the layout system to 'fall behind' and stop drawing to screen.

from microsoft-ui-xaml.