Base zoom speed on browser refresh rate

[lukemckinstry]

Description

Bases zoom speed on the render rate of the user's browser.
Added a field in frameState to track the timestamps of the 10 most recent renders.
Then when calculating the zoom distance on each frame, adjust it based on the fps zoom speed to provide consistent experience for browsers with different speeds.
The if the user wants faster or slower zoom, they can still adjust zoomFactor through the public api as before with the same effects.

Issue number and link

#12187

Testing plan

Author checklist

• I have submitted a Contributor License Agreement
• I have added my name to CONTRIBUTORS.md
• I have updated CHANGES.md with a short summary of my change
• I have added or updated unit tests to ensure consistent code coverage
• I have updated the inline documentation, and included code examples where relevant
• I have performed a self-review of my code

[github-actions]

Thank you for the pull request, @lukemckinstry!

✅ We can confirm we have a CLA on file for you.

[lukemckinstry]

posted this for initial review/feedback/discussion @ggetz. I still need to add unit tests.

[javagl]

This looks somewhat similar to what I dumped into a forum thread a while ago. The goal there was also to have an "average frame rate over the last n frames".

In that forum thread, I put this into some FpsTracker class. The reasons may be obvious. The functionality is encapsulated in a class where the name says what the class does (/* An FpsTracker tracks the FPS */ 😁 ). It offers a getAverageFps function directly. It avoids that const timeStamps = object._scene.frameState?.timeStamps; (aka Train Wreck). And it avoids the manual computation (with magic constants like 10 and 30) inside the handleZoom function.

The purpose of that FpsTracker there was to plug it into some MsseUpdater, which was supposed the update the maximum screen space error based on the average FPS. (Fleshing this out into a real feature is still on my TODO list - I think that this could make a whole lot of sense...).

tl;dr : If there was "something" where a function like getAverageFps was offered, then this could probably be re-used in multiple places...

[lukemckinstry]

I like your idea to create a FpsTracker class to make this more reusable. I will work on this change and update this PR when it is ready.

[ggetz]

I like the idea of isolating the average FPS logic in one place. The update itself should probably still happen in Scene.js though, (as @lukemckinstry just implemented).

[ggetz]

Since we are accessing this from another class, can we expose this as fpsTracker with a getter? It can be marked as @private so it doesn't show up in the developer API documentation.