False zoom location with zoomWithWheel when having a large panzoom element

Describe the bug

We are using Panzoom to be able to zoom in and out in a large "design board" (20000 x 20000 px) that has inside many other div elements. Sometimes when using zoomWithWheel and while keeping the cursor steady, the board pans to a different direction than just zooming to the certain point.

After investigating a bit, I found out that transforming a board this large and with so many elements can take time, so when using zoomToPoint from zoomWithWheel and getting the dimensions using getDimensions it gets the dimensions of the panzoom element before transforming it. So when adjusting the clientX/clientY for HTML elements, the actual dims.elem.width and dims.elem.height are not the expected.

panzoom/src/panzoom.ts

Lines 391 to 397 in 7428761

    
           // Adjust the clientX/clientY for HTML elements, 
        
           // because they have a transform-origin of 50% 50% 
        
           if (!isSVG) { 
        
             clientX -= dims.elem.width / scale / 2 
        
             clientY -= dims.elem.height / scale / 2 
        
           }

Your environment

Version of panzoom: 4.5.1
Browser and browser version: Tested on Windows: Chrome & Firefox, macOS: Chrome (mouse & trackpad)

Expected behavior

When zooming in a large panzoom elements with many contents, it should zoom correctly to the certain point

Actual behavior

The panzoom element zooms to a wrong location

Steps to reproduce

To reproduce it instead of having a very large panzoom element that can have different results, we can simulate fast wheel events.
I've created an example here.

In this test, there is a small red point element that if you zoom in on it, it should stay inside another blue element.
First reset the board and then you can click the Wheel Event Buttons to test it.

Thanks for opening an issue. I think this is related to the async nature of Panzoom and its dependence on rendered dimensions. However, I looked at your "temporary fix" and I like the idea of using ResizeObserver. The current library hasn't yet dropped IE11. I've wanted to do a rewrite for a while now and dropping IE11 and its related workarounds is part of that. When that happens, I could use ResizeObserver to track dimension changes. I don't know if that would solve every case. It would depend on the frequency of updates and when they come in as they relate to the frequency of renders for an element that is mid-animation. Anyway, you've given me a good idea here. However, I don't know if this will result in a change to the current library until the rewrite, but I'd be willing to look at a PR. Thanks!

Unfortunately the ResizeObserver does not get triggered on time, so there is an issue with the tests where I had to call skipFrame after changing the dimensions of the panzoom element here.

This is not a proposed solution yet, it's just a fix so we can use your library without any issues as we do not resize our panzoom element.

	// Adjust the clientX/clientY for HTML elements,
	// because they have a transform-origin of 50% 50%
	if (!isSVG) {
	clientX -= dims.elem.width / scale / 2
	clientY -= dims.elem.height / scale / 2
	}