Display artifacts on locked subtrees

[victorporof]

Painting retained “snapshots” at the old size might not always be desirable: when layout is altered on “locking roots”, some subtrees could have unpainted areas while others would clip. This is especially evident in suggested use-cases such as “resizing multi-pane UI with complex layout within each pane” as described here.

An example for how this can be gracefully handled is with macOS's fullscreen window management, which has a similar approach to resizing 2 side-by-side half-screen windows, where everything is blurred out to avoid relayout while resizing.

Should this responsibility be solely offloaded to the consumer of this API? Or is it worth considering having the user-agent handling these situations more gracefully by default?

[chrishtr]

Should this responsibility be solely offloaded to the consumer of this API? Or is it worth considering having the user-agent handling these situations more gracefully by default?

It's a good question. Do you have a suggestion for what to do?

[victorporof]

It might be interesting allowing the users of this API to submit a custom rendering context which would be displayed instead of the retained renderbuffer or display items. I recall some prior propositions about defining “placeholders”, instead of snapshotting, so I'm noting that here for reference.

In terms of ergonomics, Houdini’s paint worklets might work well here, where the render output could get attached as the CSS background of the locked element for display. This should allow for good performance with dynamic visual content for locked subtrees.

One possible downside to this would be "splash screen" or "loading indicator" syndrome, but that doesn't seem too troubling.

[vmpstr]

Currently the plan is to blank the pixels on locked subtrees. Possible future work like render=async would probably revisit this.