W3C home > Mailing lists > Public > public-css-archive@w3.org > July 2019

Re: [csswg-drafts] [resize-observer] device-pixel-border-box size (#3554)

From: Chris Harrelson via GitHub <sysbot+gh@w3.org>
Date: Fri, 19 Jul 2019 02:04:41 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-513060543-1563501880-sysbot+gh@w3.org>
> There's simply not time to re-render a webgl frame in response to a late resize observer event.

For sure there is less time before the next vsync.

> For the purposes of a preponderance of WebGL content, if the resize event comes after RAF if it comes at all, that's a frame of latency.

Yes, the frame is delayed, and if it misses vsync there is an extra frame’s delay. I thought you were talking about wrong frames, not delays to a frame.

With a `ResizeObserver` approach, on the frames where the canvas happens to resize (which are rare), then two WebGL rendering updates will occur and the frame will take longer to draw to the screen. However, all other frames are unaffected. And on top of that, there will *never* be a wrong frame (defined as a frame where the WebGL drawing does not properly match the sizing of the canvas element.

With a `getBoundingClientRect * devicePixelRatio` approach, or even if `getBoundingDeviceRects` were added, in simple situations you can indeed call `getBoundingDeviceRects` during a rAF callback and resize & re-draw the canvas. However, wrong frames are impossible to avoid in general, because of situations like:

* Another rAF callback unrelated to the WebGL one may run after it in the same frame, and may change DOM in a way that changes the layout size of the canvas.
* A ResizeObserver on another element could also cause layout to change, with the same result.

I do not think these situations are uncommon in complex apps. When encountered, the only way to avoid them is try to coordinate all activity on the page, leading to lots of complexity for the developer. Or in many cases, they will just accept a worse web app and the web is worse for it. `ResizeObserver` exists to solve this exact problem, in a decentralized way, that is pretty easy to use.

Further, if the canvas is quiescent and not updating its drawing, there is no solution to detecting when it resizes, except polling or adding a new resizing event callback, which suffer from the problems above as well. `ResizeObserver` also solves this problem with no additional work for the developer.

> I can join the next CSSWG call.

Great, thank you.

GitHub Notification of comment by chrishtr
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3554#issuecomment-513060543 using your GitHub account
Received on Friday, 19 July 2019 02:04:43 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:50 UTC