Resizing of panels is slow when there are many nodes in resized notebooks/widgets

[krassowski]

Description

Resizing split/dock panels is slow. #504 proposes a solution for bottom-down resizing which is specific to Chrome.

Reproduce

As in #504 but left-right.

Expected behavior

Resizing does not jitter the UI allowing users to precisely set the layout they need at a first attempt.

Proposed solution

When we start the drag action of a SplitPanel we could throttle the relayout of the contents.
This requires isolating the contents of the panel to preserve its layout by pinning width and height, adding contain:strict and then updating the width/height every once in a while to match the size of the outer container.

There is a trade-off: throttling the contents updates would mean that contents are sometimes out of sync with the container size. Some applications deal with this by stretching the contents in compositor (using transform: scale) but it only looks good if the content has little text and resizes proportionally rather than reflowing.

Ideally we would be able to only isolate the problematic elements. With windowed notebook in 4.x we are not concerned about the notebook having many cells but about cells having large outputs*, e.g. an SVG with 1000s elements ; if we could contain the SVG size (throttle its updates) for the time of resizing, the UX would be much nicer as the overall layout of notebook would still reflow smoothly.

Technically we would need to implement a special method in split panel children to handle requests:

• "isolate large elements" (invoked by SplitPanel when user starts resizing)
• "update size of isolated elements" (invoked by SplitPanel with throttling on mousemove when resizing)

*) or by individual cells having incredibly long code, say thousands of lines

[vidartf]

An alternative to throttling the relayout is to replace the content of a node with a placeholder image (not a screenshot but a generic "ui element here" image). We might also be able to only do this conditionally if we detect that layout events are slow (e.g. we are resizing a panel, and start updating layout as we go. This assumes that we can know when the layout has completed).