OffscreenCanvas

TL;DR / OffscreenCanvas decouples canvas rendering from the main thread, allowing 2D and WebGL drawing operations to run in a Web Worker without blocking UI responsiveness.

How It Works

      Main Thread                       Worker Thread

  ┌──────────────────┐   transfer   ┌───────────────────┐
  │     <canvas>     │─────────────→│  OffscreenCanvas  │
  └──────────────────┘              └───────────────────┘
                                              │
  transferControlTo                           │
  Offscreen()                                 │
                                              │
                                              ↓
  UI stays responsive               ┌───────────────────┐
                                    │ getContext("2d")  │
                                    │     or WebGL      │
                                    └───────────────────┘

                                    Render without blocking

Edit diagram

Canvas rendering on the main thread competes for time with DOM updates, event handling, layout, paint, and JavaScript execution. A complex WebGL scene or a heavy 2D drawing operation can drop frames and cause visible jank. OffscreenCanvas solves this by moving the rendering work to a Web Worker, where it runs on a separate thread without contending for main thread time.

Two Modes of Creation

There are two distinct ways to use OffscreenCanvas:

Transferred from a DOM canvas. You start with a visible <canvas> element in the DOM, then call canvas.transferControlToOffscreen(). This returns an OffscreenCanvas object that you transfer to a worker via postMessage. The worker draws to it, and the browser composites the result back into the DOM canvas automatically. The main thread can no longer draw to that canvas — ownership has been transferred.

Created standalone in a worker. You create new OffscreenCanvas(width, height) directly inside a worker, without any corresponding DOM element. This gives you an off-screen rendering surface for generating images, processing pixel data, or preparing textures. You can extract the result with convertToBlob() or transferToImageBitmap() and send it back to the main thread.

The first mode is for real-time rendering (games, visualizations, animations). The second is for image processing pipelines (thumbnail generation, filters, canvas-based image manipulation).

Rendering Contexts

OffscreenCanvas supports the same rendering contexts as a regular canvas: "2d" for the Canvas 2D API, "webgl" and "webgl2" for WebGL, and "bitmaprenderer" for efficient image bitmap display. You obtain a context with offscreen.getContext('2d') and use the same drawing API you already know. The API surface is nearly identical — the key difference is where the code executes, not how you call it.

For WebGL, offscreen rendering is particularly valuable. WebGL draw calls are synchronous and can stall the main thread while the GPU processes commands. Running them in a worker means the main thread is free to handle input events, run animations, and update the DOM while the worker submits GPU work.

Animation Loops in Workers

On the main thread, you drive canvas animations with requestAnimationFrame. Workers also have access to requestAnimationFrame when using a transferred OffscreenCanvas — the browser ties the callback to the compositor's vsync signal. This is the preferred approach for smooth animations. Alternatively, the worker can use setTimeout/setInterval or receive frame ticks from the main thread via postMessage.

When you draw to a transferred OffscreenCanvas, the browser schedules composition with the next display frame automatically. The worker manages its own render loop while the compositor presents the latest completed frame.

ImageBitmap Bridge

OffscreenCanvas.transferToImageBitmap() creates an ImageBitmap from the canvas's current content and clears the canvas for the next frame. The ImageBitmap can be transferred (zero-copy) to another thread. This is useful for double-buffering: the worker draws to the offscreen canvas, extracts an ImageBitmap, transfers it to the main thread, and the main thread displays it on a DOM canvas using bitmapRenderer.transferFromImageBitmap(). This pattern gives you explicit control over frame presentation timing.

Pixel Manipulation

For CPU-intensive pixel operations (convolution filters, histogram computation, color space conversion), the workflow is: create an OffscreenCanvas in a worker, draw the source image with drawImage, extract pixel data with getImageData, process the array, put it back with putImageData, and transfer the result to the main thread.

Since typed arrays are transferable, you can skip the canvas entirely for raw pixel math. But OffscreenCanvas is convenient when you need the canvas API for compositing, text rendering, or path operations alongside pixel processing.

Performance Considerations

Moving rendering to a worker does not make it faster in absolute terms — the drawing operations take the same CPU/GPU time. What it does is remove that work from the main thread's task queue, preventing it from blocking input handling, React renders, or DOM updates. The user perceives the application as smoother even though total work is identical.

The overhead is minimal: the OffscreenCanvas transfer is a one-time operation. The main cost is coordination complexity — managing shared state, handling resize events (the main thread must communicate new dimensions), and synchronizing user input with the worker's render state.

Gotchas

  • No DOM API access — the worker cannot read element positions, CSS styles, or device pixel ratio directly. The main thread must send these values and update them on resize or zoom.
  • transferControlToOffscreen() is one-way — once you transfer a canvas to a worker, the main thread cannot draw to it ever again. There is no mechanism to reclaim control.
  • Safari support has quirks — Safari added OffscreenCanvas support in version 16.4 but with limitations: 2d context support came later than WebGL, and some methods like convertToBlob may behave differently.
  • Resize coordination is manual — when the main thread canvas resizes (CSS, window resize), you must send the new dimensions to the worker and update the OffscreenCanvas width/height there. Forgetting this produces stretched or clipped output.
  • requestAnimationFrame scope is limited — workers have requestAnimationFrame only when a transferred OffscreenCanvas is present. Without one, you must use setTimeout or message-based frame ticking, which may not sync with the display refresh rate.