OffscreenCanvas
Slap yourself if
You think OffscreenCanvas automatically makes rendering fast or assume it just moves canvas code to a worker with no consequences.
Why this exists
Because teams adopt OffscreenCanvas to escape main-thread jank and end up with harder debugging, subtle synchronization bugs, or no performance gain at all.
Mental model
OffscreenCanvas is not a faster canvas. It is a different execution topology where rendering can happen off the main thread, but presentation, coordination, and memory costs still exist.
- A canvas is detached from the DOM and represented as an OffscreenCanvas.
- Rendering commands can execute in a worker context.
- The result is transferred or committed back to the visible canvas.
- Main-thread layout and compositing still determine when pixels appear.
- Assuming worker rendering removes all main-thread work.
- Overusing message passing and killing any gains.
- Expecting DOM or layout access inside workers.
- Measuring FPS instead of input latency and jank.
OffscreenCanvas allows canvas rendering to run off the main thread, but presentation and coordination remain main-thread concerns with real tradeoffs.
- Calls it GPU rendering.
- Assumes zero main-thread involvement.
- Ignores transfer and synchronization costs.
- Frames it as a universal canvas optimization.
Deep dive
Requires Pro
Premium deep dives include more internals, more scars.