Web Workers and Canvas

Question

Are web workers allowed to access a canvas object?

Solution 1

Small update, as the question is now more than half a year old:

In Chrome/Chromium 6 you can now send a canvas' ImageData object to a web worker, let the web worker make changes to the object and then write it back to the canvas using putImageData(..).

Google's Chromabrush does it this way, the source-code can be found here:

• Main thread
• Web worker

Update:

The latest development snapshots of Opera (10.70) and Firefox (4.0b1) also support passing ImageData objects to a web worker.

Update 2017:

Actual links from Github (easier to find needed files from Chromabrush):

• Sending imageData to worker
• Receiving data

Solution 2

Newer browsers support OffscreenCanvas (see the browser compatibility in that doc), which is a canvas 2d context that runs in web workers, but automatically paints to the main thread.

The following is the basic example from that MDN doc.

In the main thread, create an OffscreenCanvas, then send it to a worker:

var htmlCanvas = document.getElementById("canvas");
var offscreen = htmlCanvas.transferControlToOffscreen();

var worker = new Worker("offscreencanvas.js"); 
worker.postMessage({canvas: offscreen}, [offscreen]);

In the worker thread, use the offscreen canvas reference to create a context like you would normally do on the main thread, and perform any drawing commands that you want:

onmessage = function(evt) {
  const canvas = evt.data.canvas;
  const gl = canvas.getContext("webgl");

  function render(time) {
    // ... some drawing using the gl context ...
    requestAnimationFrame(render);
  }

  requestAnimationFrame(render);
};

(The requestAnimationFrame API exists inside the worker.)

Solution 3

No.

The postMessage spec was updated a few months back to allow you to post ImageData objects but as yet no one has implemented that behaviour (we're all getting there). The problem with canvas itself is that it's a DOM element and so doesn't work in a worker (there's no DOM).

This was raised recently on either the whatwg or web-apps mailing lists so i suspect we'll start looking at whether it's possible to provide a CanvasRenderingContext2D-like api in workers.

Comments

[James Black]

I was under the impression the WebWorker wouldn't allow any interaction with a DOM as that would run into possible problems if multiple webworkers are making changes.

[olliej]

The problem is that the DOM has no concept of concurrency, so Workers don't allow any shared state. The only way of communicating with a worker is with postMessage, and that performs a clone according to the "internal structured cloning algorithm" which can basically be thought of as JSON but with additional support for a few key types (File, FileList, ImageData, Blob, Date and RegExp)

[Baxissimo]

This answer is out of date. The other answer is now better.

[Lothar]

It would make sense to give a webworker it's own DOM and then allow an API to switch part of the DOM. Considering that one reason was to allow multithreading, this is a pretty unusable feature now. Canvas drawing can be very expensive, so i don't understand the WHATWG

[Lothar]

Let me guess IE is different ?

[DeusProx]

It probably copies the whole thing while sending it to the webworker and also copies the transformed data back to the main thread to draw it into the canvas? So two times copying the whole decrypted picture including speed penalty?

[DeusProx]

Or is it really guaranteed pass by reference for some data types?

[tsauerwein]

@DeusProx Yes, a copy is made. You could try to use Transferable Objects.

[Wolfgang]

Using imageData as TransferableObject works for me (where supported). This avoids creating a copy of the whole array but please notice: as soon it's 'transfered' to the worker (by reference) it's not accessible anymore in the main thread