- From: Khushal Sagar via GitHub <sysbot+gh@w3.org>
- Date: Fri, 10 Nov 2023 17:29:40 +0000
- To: public-css-archive@w3.org
Sorry for the late reply and thanks for clearly outlining the feature request @mattgperry! The reason why it's hard to make capture synchronous is that we need to run the [update the rendering](https://html.spec.whatwg.org/#update-the-rendering) loop for it. Making it synchronous would mean that this loop has to be triggered from within a script call, `startViewTransition()`. That changes a fundamental assumption across all browsers that the rendering loop runs from a vsync driven new task on the main thread's event loop. Browsers generally have the Document's last rendered frame cached. If we only had to snapshot the root, we could've provided that frame as the snapshot (it will be limited to the DOM state from the last rAF). But snapshotting elements independently affects layerization and a bunch of rendering decisions at every step in the pipeline. Its just not feasible to do it outside of a rendering loop. So we have to wait until the next rendering loop after `startViewTransition()` is dispatched and that's why it has to be an async operation. Can you clarify why async snapshotting is hard for frameworks to accommodate. It looks like you want to trigger a synchronous snapshot operation at the end of "big chunk of interruptible work". Since the big chunk of work is meant to be interruptible by design (for interactivity), it should be possible to yield for a frame between "big chunk of interruptible work" and "DOM Update". That gives the browser the opportunity to snapshot at the next frame. The delay after the next frame finishing and the updateCallback getting dispatched should be very less. Maybe I'm missing the complexity on the framework side here. -- GitHub Notification of comment by khushalsagar Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9400#issuecomment-1806140520 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 10 November 2023 17:29:42 UTC