The FrameAPI provides functions for registering and unregistering
frame listeners which are executed on every tick
of the internal update loop of the webvis context.
The FrameAPI might be used to:
process events that have been collected between frames in a batched manner
perform complex animations that cannot be implemented using the AnimationAPI
record properties of the scene, like the camera position and orientation
Quick Start
To get started with the FrameAPI, you can register a listener via the webvis context:
constcontext = webvis.getContext();// Define your frame listenerconstmyFrameListener = (time, elapsed) =>{console.log(`Time of current tick: ${time} ms. Time since last tick: ${elapsed} ms.`);};// Register your frame listenercontext.registerFrameListener(myFrameListener);// Later unregister your frame listenercontext.unregisterFrameListener(myFrameListener);
Execution Behavior
The execution frequency of a frame listener will usually match the refresh rate
of the display, which is typically around 60 Hz. Frame listener execution might
be throttled when the document is not visible (e.g., when the browser tab is in
the background).
When executed, a listener receives the timestamp of the current tick of the
internal update loop and the elapsed time since the last tick. Custom logic
should never assume a specific update rate, but instead be based on the provided
timing information.
FrameAPI
Overview
The FrameAPI provides functions for registering and unregistering frame listeners which are executed on every tick of the internal update loop of the webvis context.
The FrameAPI might be used to:
Quick Start
To get started with the FrameAPI, you can register a listener via the webvis context:
Execution Behavior
The execution frequency of a frame listener will usually match the refresh rate of the display, which is typically around 60 Hz. Frame listener execution might be throttled when the document is not visible (e.g., when the browser tab is in the background).
When executed, a listener receives the timestamp of the current tick of the internal update loop and the elapsed time since the last tick. Custom logic should never assume a specific update rate, but instead be based on the provided timing information.
See