If the size of the canvas is on a transition, sometimes the size calculations are wrong.

[unphased]

It looks like this is quite an antipattern to be using, as it seems like browsers allow you to animate sizes like this, and it would cause canvas (and hence renderbuffer resizing) at a high frequency, which is an absurd thing to want and yields horrendous performance anyway.

I was wondering if maybe we could detect this at runtime and emit some helpful messages. I've got a side nav that is animated and it was yielding some subtle x-axis raycast offset issues for obvious reasons (the animated resize of the canvas probably choked up whatever is being used to compute the sizing and used by raycasting).

[drcmda]

not sure i understand the question. it uses a resizeobserver to catch bounds, which it then uses to set up the raycaster.

[unphased]

Sorry I didn't provide good context. So R3F employs a system that automatically determines the dimensions of its canvas. This is very useful. However I found a situation in which it does not seem to be working too great, which is when you have a layout that is implemented in such a way that the dimension of the element changes on a CSS transition animation. This is extremely bad because there's no way that the framebuffer resizing could keep up with animation frametimes, and the result is a poor experience. In particular I've found (at least with my app) in certain situations the dimensions used by raycasting does not match the actual canvas dimensions, and the issue is gone after removing such transitions. Hence I was suggesting it may be a good idea to have a detection mechanism for resize handlers firing too often on the canvas, and for it to provide a developer targeted warning against the use of this kind of layout.