fix: Use requestAnimationFrame with ResizeObserver #10282
Conversation
Modified ResizeObserver to use requestAnimationFrame for better performance in Safari.
|
web-padawan
left a comment
web-padawan
left a comment
There was a problem hiding this comment.
Is there any particular case where you were able to observe performance problems? If so, please create an issue first. I understand that it might be difficult to cover the change with a unit test but ideally we would have at least a test to cover timings change.
| // Use requestAnimationFrame to avoid performance issues with Safari | ||
| this.__resizeObserver = new ResizeObserver(() => { | ||
| const ironListAdapter = this; | ||
| requestAnimationFrame(() => ironListAdapter._resizeHandler()); |
There was a problem hiding this comment.
A debouncer would be preferable here, since it also eliminates unnecessary resize handler calls
There was a problem hiding this comment.
Yes, that would work too.
There was a problem hiding this comment.
Calling _resizeHandler right inside the ResizeObserver callback has performance advantages. Layout is already computed at that stage, but the frame hasn't been painted, so reading such properties as scrollWidth or using getComputedStyle shouldn't generally cause a reflow as long as the layout has not been dirtied again. We will lose this benefit if _resizeHandler is deferred until the next frame.
Also, delaying _resizeHandler to the next frame may not fix the issue and could just make it asynchronous.
We need a reproducible example to confirm that this change actually fixes the issue.
Modified ResizeObserver to use requestAnimationFrame for better performance in Safari.