Description

• tackles Resizing of panels is slow when there are many nodes in resized notebooks/widgets #505
• this is an early draft; I plan to resolve duplication and drop some changes to reduce diff later on

Trigger condition

• using the Performance API works but we can detect the longtask or long-animation-frame but it comes after user already saw a freeze for a few seconds; I think this is not the right approach - the Performance API was designed primarily as a measurement tool, not to make the rendering system reactive.

Freeze implementation

• using contain: strict alone is not enough because it tells the layout engine that when considering layout of parents it can use the size as given in width/height but the browser still needs to relay all the text nodes inside the widget, which is more expensive
• we can address this by using minWidth/maxWidth on the widgets with many children; it works but it is still not as fast as it could be; we know that it could be faster because resizing the same panels top-down is super smooth (without tricks) since we enabled strict containment. I believe that the difference is that the leaf layout, including text reflow, is never touched in top-down resize because the content is just scrolled rather than re-laid
• freezing the sizes of all leaves of heavy widgets does give a smooth resizing experience; this allows the rendering pipeline to skip layout of the contents altogether when resizing
• I was also experimenting with applying content-visibility: auto to DOM children of heavy widgets, I am yet to confirm if this is warranted in the final form

Freezing the width means that the Widget in panels which have overflow: auto enabled get scrollbars, which you can see on the recordings below.

Throttled/delayed updates

• we can update periodically to ensure user gets some idea of how the content will look like; the more often we perform the update, the more jittery the resize is. In recordings below I am using updates once every 3 seconds
• we can update when user pauses resizing; currently I wait 300ms to decide if user paused resizing
• the updates are staggered, doing things one panel (group) at a time, spread across frames to avoid any long tasks/dropped frames

Before

After (active on pointer down, no long animation frame detection)

After (activates only after long frame/task detection)