Vector Vesper Runtime · Frame-time discipline

The rendering failures that never throw.

This is for pages doing real rendering work: WebGL scenes, canvas effects, scroll-driven media, and interactions heavy enough that the frame budget is a constraint you can feel.

A scene mounts while the reader is still scrolling and the page hitches. A context is lost and the canvas stays black. Quality flips between tiers twice a second. None of it raises an error, fails a test, or shows up as a red type. These are primitives for that class of problem: deciding when work runs, at what quality, whether it should run at all, and being able to see where the frame actually went.

Start with an effect

You do not need to learn the runtime before adding motion. Effects are the shortest path for common interactions, and they already participate in the same shared loop.

Underneath, every effect subscribes to one frame loop. That is the mechanism the decisions above are built on: sensors read layout before anything writes it, and work is dropped by declared priority when a frame runs long.

What the runtime does

Whether it runs at all

Scene gate decides if a heavy canvas should mount yet, pauses it off screen without discarding the GPU context, and rebuilds it when that context is lost.

At what quality

Adaptive quality fuses what the hardware can do with what the page is actually managing, then holds the decision steady so detail does not flicker between tiers.

Where the frame went

DevTools split a frame into what the runtime cost and what everything else did, so you can tell whether the problem is your code, React, paint, or the GPU.

Game-engine principles, applied to web motion

A game engine is a runtime that coordinates real-time work within a fixed frame budget. Vector Vesper applies the same useful disciplines to browser motion: one scheduler, clear phases, shared input, quality levels, scene lifecycle rules, and frame-level diagnostics. The constraints are the same even though the output is a web page: a fixed budget per frame, work that has to be ordered, and a device you do not get to choose.

Priority-based task shedding

Motion that degrades on purpose

Shared tickers are not new on the web, and ordered read-then-write phases are not either. What is missing almost everywhere is a decision about what to drop when the frame runs out. Without one, a long frame degrades everything on the page equally, including the interaction the reader is currently touching. Vector Vesper borrows priority shedding from game rendering pipelines: decorative work is skipped for that frame while essential work still runs. Nothing starves, since work skipped too often is forced through.

01 · EssentialLocked 60 FPS

Direct user inputs, pointer tracking, scroll scrubbers, and gesture physics. Never dropped.

02 · EnhancedDynamic 30-60Hz

Secondary animations, card springs, and parallax layers. Throttled to 30Hz under frame pressure.

03 · DecorativeShed first

Ambient canvas shaders, noise fields, and floating particles. Shed first when frame budget runs short.

Game-engine principle	Vector Vesper runtime	Why it matters
Central game loop	Frame Conductor	One coordinated frame loop instead of every effect creating its own.
Update/render phase separation	Frame lanes — input → update → render	Sensors read layout before anything writes it. Layout thrashing is prevented by construction, not by everyone remembering.
Variable timestep with clamping	Clamped dt	A backgrounded tab waking up can't feed a huge delta into damping math and blow the first frame apart.
Decoupled update rates	hz throttling	Run ambient work at 30Hz while interaction stays at display rate. Accumulated dt is passed through, so motion stays frame-rate independent — identical look, half the cost.
Centralized input	Sensor Bus	Pointer, scroll, and viewport signals are collected once and shared across systems.
Frame budgeting	Animation Budget	Treats frame time as a finite resource and prioritizes important work when frames get expensive.
Priority-based task shedding	Priority bands — essential / enhanced / decorative	When a frame runs long, decorative work is dropped for that frame rather than everything degrading together. Nothing starves: work skipped too often is forced through.
Adaptive quality / LOD	Adaptive Quality	Reduces visual complexity when frame health drops instead of letting the entire experience degrade.
Hardware presets	Device tier floor	GPU renderer, WebGL2, cores and memory are read once to set a floor the runtime cannot drop below — the equivalent of picking Low/Medium/High at startup. An Apple GPU counts as mobile-class only on a touch device, so a Mac on Safari starts at full quality.
Deferred activation	useSafeToMount / useSceneGate → useSceneGate	Expensive scenes wait until the page is ready and conditions are safe.
Visibility culling	Scene Gate idle state	Scrolled off screen, a scene pauses its render loop but keeps its GPU context and textures. Unmounting would throw both away to save nothing.
Device-lost recovery	Renderer Health	A lost graphics context is detected and the scene rebuilds. Without it a WebGL page goes permanently black with no error.
Frame-based timing	Conductor timing / damp	Continuous motion is driven by frame timing rather than assuming a fixed refresh rate.
Runtime telemetry	Runtime DevTools	Makes active systems, frame costs, and runtime behaviour observable while the page is running.
System architecture	Runtime hooks	Motion features plug into a common runtime rather than behaving as isolated effects.

Choose a starting point

I need an interaction

Start with an effect hook for magnetic elements, pointer intent, scroll-scrubbed video, number tickers, or image trails.

I am adding a 3D scene

Use scene policy to decide when a heavy canvas should mount, render, reduce quality, pause, and recover.

The page is getting slow

Measure first. DevTools and frame pressure show where frame time is actually going before you tune the experience.

Let the system grow with the page

Most projects stop at the first step. Add the next layer only when the problem appears; each one solves a different kind of coordination or performance concern.

01
Start with the effect you need
For a single interaction, use an effect hook. You get a focused API; the shared runtime is already underneath it.
Browse effects
02
Coordinate custom motion
When you write your own per-frame work, subscribe to FrameConductor instead of creating another requestAnimationFrame loop.
Use FrameConductor
03
Add policy for expensive scenes
A WebGL scene needs more than an intersection observer. Scene policy covers visibility, headroom, quality, and context recovery together.
Use scene policy
04
Measure before you optimize
When frames slip, determine whether runtime work, other main-thread work, or rendering is responsible. The fix depends on the cause.
Inspect frame pressure

I want to…

Run custom work every frameuseTick Read pointer, scroll, or viewport stateSensorBus Smooth a value at any refresh ratedamp Wait to mount an expensive elementuseSafeToMount Run a plain three.js sceneuseThreeScene Gate any heavy scene or sectionuseSceneGate Adapt a React Three Fiber canvasuseRenderQuality Rebuild a WebGPU scene when the device is lostwatchGPUDevice Protect direct manipulation from background workInteractionScope Understand a missed frameDevTools and useFramePressure

Use a platform feature when it is enough. A hover state is usually CSS. A simple mount fade is a transition. The runtime is for work that needs continuous input, shared scheduling, or policy under real frame pressure.

Shipping this at scale? If you are running heavy scenes in production, on client work, or across a team, we want to hear what broke. The failures that matter most are the ones we have not hit yet. Tell us.