[whatwg] Canvas in Workers

Ian Hickson ian at hixie.ch
Tue Jan 8 14:49:09 PST 2013

On Tue, 8 Jan 2013, Gregg Tavares wrote:
> >
> > Supporting page flipping in 2D canvas would be fine too, but I don't 
> > see why it would need a change to the API... you would just make 
> > "commit()" flip which page was active for the context API and clear 
> > the newly active page in one operation.
> How would you choose flip vs copy with just commit?

An argument to the context constructor, probably.

> Just to be clear we're on the same page. I want to be able to do this 
> (not related to workers)
>    // create a 2d context that flips buffers instead of copies them
>    var ctx = canvas.getContext("2d", { preserveDrawingBuffer: false });

I would do it like this:

   var ctx = new CanvasRenderingContext2D(100, 100, { mode: 'pageflip' });

   ctx.commit(); // implies clearRect(0,0,100,100);

   // later
   ctx.commit(); // implies clearRect(0,0,100,100);

> But, related to workers, if CanvasProxy is truly a proxy for the canvas 
> then I could do this
>    // create a 2d context that flips buffers instead of copies them
>    var ctx = canvasProxy.getContext("2d", { preserveDrawingBuffer: false });

CanvasProxy doesn't have getContext(), because the direct mode doesn't 
make sense cross-process. You would do:

   var ctx = new CanvasRenderingContext2D(100, 100, { mode: 'pageflip' });

   // draw...

> Agreed but that's a separate problem

These are all related problems that contribute to the design of the same 

> Problem #1) Allow a worker to render to a canvas
> Problem #2) Allow a worker to render offscreen (without communicating with
> the main page)
> I'm suggesting we only solve problem #1 for now. To do that, all we need 
> is CanvasProxy to truly be "a proxy for the canvas".

I'm solving #2 now too. (Actually it's already solved in the spec.) I'm 
happy to only discuss #1 if you want, but #2 influences the design of the 
API for #1 so the conversation will be weird if we ignore #2.

> > setContext() is only needed so that you can use one context with 
> > multiple canvases, which is primarily intended to address the WebGL 
> > case of having one context used to render to multiple views with 
> > different settings (the settings being themselves set on the canvas or 
> > canvas proxy).
> Right, but since it doesn't doesn't seem to work for WebGL's needs why 
> spec it now when we can solve problem #1 today and worry about the other 
> problems later?

It seems to work fine as far as I can tell, as shown by the examples in my 
recent e-mail.

> > > Is there some reason that won't work?
> >
> > Well I'd rather not design something that doesn't address a known 
> > issue and then find we have painted ourselves into a corner with 
> > respect to that other issue. Hence trying to solve all the issues at 
> > once, or at least solve them in a way that is compatible with future 
> > solutions.
> Agreed. I'm just trying to make forward progress.

At this point I'm not aware of any problems with the current proposal 
(what's in the HTML spec plus adding setSettings() in WebGL, making the 
WebGLRenderingContext constructable, and providing an in-worker 
alternative destination for WebGL for when you don't want to draw to a 
canvas, as discussed in my earlier e-mail today).

> I'm wondering if we can separate the 2 issues by just making CanvasProxy 
> be "a proxy for the canvas" with the same API as Canvas.

That doesn't work for 2D. The original API (getContext) relies on implicit 
commits, and we can't do implicit commits sanely in a worker. That's the 
main reason for having a different mechanism (setContext).

Anyway, I don't really understand what's wrong with the proposal that 
addresses all the problems that have been raised at once. I don't see a 
need to do this bit by bit when we've already got a full solution.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

More information about the whatwg mailing list