- From: Joe Pea via GitHub <sysbot+gh@w3.org>
- Date: Sun, 17 Dec 2023 21:55:33 +0000
- To: public-css-archive@w3.org
trusktr has just created a new issue for https://github.com/w3c/csswg-drafts: == [resize-observer] why we need `ResizeObserver.takeRecords()` or `ResizeObserver.hasRecords()` == Spec: https://drafts.csswg.org/resize-observer/#resize-observer-interface There's one main problem with ResizeObserver and rendering using canvas: - people typically use `requestAnimationFrame` for animating - ResizeObserver is used for handling size changes - ResizeObserver callbacks run _**after**_ animation frame callbacks - A user's animation frame loop typically includes an update to canvas (f.e. WebGL) - when ResizeObserver runs _**after**_ animation frames, a second render-to-canvas will be needed so that the drawing will be correct, or else the problem of canvas flickering will happen due to resize clearing canvas pixels before browser paint. See: - https://github.com/WICG/resize-observer/issues/37 - https://github.com/pixijs/pixijs/issues/3395 - https://codepen.io/trusktr/pen/EzBKYM (change the variable `SHOW_FLICKER_PROBLEM` to `true` at the bottom, then repeatedly resize the example) - @atotic [made some suggestions](https://github.com/WICG/resize-observer/issues/37#issuecomment-289546949) that are definitely not ideal for users: - > perform resize inside rAF, then draw - This is not possible, because ResizeObserver callbacks run _**after**_ animation frames - A new animation frame can be requested so that resize happens in the *next* animation frame before draw, but then the drawing will always be one frame behind, making resize look clunky - > skip drawing in rAF, draw in RO callback - This is not possible. The point of RO is to detect size changes, and we don't know about size changes until RO callbacks run. There's no way to know if ResizeObserver has records queued, so that we can conditionally skip drawing in rAF and instead draw in RO callbacks. So, how do we know that we need to avoid drawing in rAF, and instead draw in an RO callback? That's where this issue comes in. If we had `ResizeObserver.takeRecords()`, we could get the records, run the resize logic in rAF, and then draw. If we had `ResizeObserver.hasRecords()`, we could skip drawing in rAF, then let the draw happen in the following RO callback. --- Note, if we get other observers like [`ComputedStyleObserver`](https://github.com/w3c/csswg-drafts/issues/8982) and [`BoundingClientRectObserver` or `ClientRectObserver` for short](https://github.com/whatwg/html/issues/9104), the same problem will exist with those if they run after rAF but before browser paint, and they should also have `takeRecords` and preferably `hasRecords`. --- An alternative API that would help with these problems would be [`requestFinalFrame` or `requestPaintFrame`](https://github.com/whatwg/html/issues/9721). The convention for web developers would become: - animate data with `requestAnimationFrame` - handle data updates in observer callbacks without worrying a drawing yet (`ResizeObserver`, `ComputedStyleObserver`, `MutationObserver`, etc) - finally use `requestFinalFrame` (or `requestPaintFrame` or whatever name we come up with) to apply final drawing/rendering. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9717 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Sunday, 17 December 2023 21:55:36 UTC