[resize-observer] ResizeObserver is too slow to be useful but required to be correct

[greggman]

AFAICT, ResizeObserver is specifically designed to be slow to respond. So, if you use it to, for example, resize a canvas animation, you end up with situations like this

Screen.Recording.2023-11-06.at.15.19.00.mov

Above the page is using ResizeObserver events to adjust the size of the canvas. notice the image gets stretched and distorted because the frequency of events from ResizeObserver is too slow to keep up with the size of the canvas.

Compare to this animation which looking up the size to make the canvas via element.clientWidth and element.clientHeight

Screen.Recording.2023-11-06.at.15.19.26.mov

This one does respond in time to update the canvas as the page resizes

The problem is, only ResizeObserver returns correct sizes via devicePixelContentBoxSize so if you want a pixel perfect display you're stuck with the first behavior instead of the second. That seems undesirable.

You could workaround the issue by some complicated solution where you first use some non-correct means like clientWidth and clientHeight or getBoundingClientRect and then try to update your incorrect guess with the correct data from ResizeObserver and devicePixelContentBoxSize but the fact that you'd have to jump through these hoops seems to suggest maybe the spec needs a revisit?

[greggman]

I think this is probably a chrome bug, not a spec bug

[Loirooriol]

Compare to this animation which looking up the size to make the canvas via element.clientWidth and element.clientHeight

These are not observers. What do you use to track changes on clientWidth/clientHeight?

Using ResizeObserver should be slower than requestAnimationFrame, but faster than 2 rAFs:

new ResizeObserver(() => console.log('ResizeObserver')).observe(document.body);
requestAnimationFrame(() => {
    console.log('requestAnimationFrame 1');
    requestAnimationFrame(() => console.log('requestAnimationFrame 2'));
});

requestAnimationFrame 1
ResizeObserver
requestAnimationFrame 2

That should be quite fast. So hard to say since you don't provide a testcase, but seems a bug in your browser or your code.

Anyways, the timing of this is part of HTML, not CSS: https://html.spec.whatwg.org/multipage/webappapis.html#update-the-rendering