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

> This feels like an abuse of the observer model,

Maybe, maybe not. The example script I gave, which fleshed out the idea @dbaron suggested, shows that there is a way to avoid the double-WebGL-render problem @jdashg raised in situations where a resize occurs. And if it turns out to be a very useful mode, we could formalize that in a new API.

Regarding GC: if it turns out to be a real problem for a WASM app of the future, it can definitely be solved pretty easily with an API tweak. 

> How do browsers like if rendering would always take place outside the rAF function?

There is nothing at all that forces developers to render within a rAF. In fact, many popular frameworks, such as React, don't actually render during rAF, in part to have more time to render than rAF allows, as rAF often tries to fire as late as it can to minimize latency to the screen.

As the Chromium rendering lead, I would say my view is that "do all rendering within rAF" is not a feasible solution for many cases, especially in complex apps, due to the issue of wasting CPU time being idle. (*)

> or does that also have the problem that rendering may occur to wrong(unsynchronized) size e.g. under continuous DOM size animation?

It has several problems; one of them is the wrong-size issue you mentioned. There is also the issue of needing to poll (or constantly rAF, which amounts to the same thing) just in case sizes change, and also that extra forced layouts can occur because `deviceWidth` would force layout, and other rAF callbacks may dirty layout also. These are mentioned in more detail in comments above in this issue.


(*) Aside that may be useful:

To address the framework use-case mentioned above, [postAnimationCallback](https://github.com/WICG/requestPostAnimationFrame/blob/master/explainer.md) is a new callback being proposed that is intended to be run after rendering is complete, so that reading back layout is more likely to be free, and to support the use cases of starting rendering of the next frame as soon as possible.

However, this callback happens "post-commit", which means that the rendering display list has already been sent to the browser for display to the screen. Doing it post-commit is important to avoid postAnimationCallback ending up being the same as ResizeObserver, and thereby accidentally delaying frames.


-- 
GitHub Notification of comment by chrishtr
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3554#issuecomment-515130236 using your GitHub account

Received on Thursday, 25 July 2019 17:13:15 UTC