[whatwg] Canvas in Workers

[Ian Hickson]

On Thu, 3 Jan 2013, Gregg Tavares wrote:
> On Tue, Dec 11, 2012 at 9:04 AM, Ian Hickson <ian at hixie.ch> wrote:
> > On Tue, 11 Dec 2012, Gregg Tavares (社ç~T¨) wrote:
> > >
> > > discussion seems to have died down here but I'd like to bring up 
> > > another issue
> > >
> > > In WebGL land we have creation attributes on the drawingbuffer made 
> > > for a canvas. Example
> > >
> > >     gl = canvas.getContext("webgl", { preserveDrawingBuffer: false });
> > >
> > > We're working out the details on how to set those options for the 
> > > case where we have 1 context and multiple canvases.
> > >
> > > The particular option above would apparently be a huge perf win for 
> > > canvas 2d for mobile. Which suggests that whatever API is decided on 
> > > it would be nice if it worked for both APIs the same.
> >
> > What does it do?
> 
> Effectively it makes the canvas double buffered.
>
> Right now by 2d canvases are effectively single buffered. At the 
> appropriate time a copy of the canvas is made and passed to the 
> compositor. This copy is slow, especially on mobile.
>
> Apple requested that for WebGL the default be for double buffering. When 
> double buffered, when the canvas is composited (when the current 
> JavaScript event exits) the canvas's buffer is given to the compositor 
> and the canvas is given a new buffer (or an old one). That new buffer is 
> cleared, meaning the contents is gone. It's up to the app to draw stuff 
> into again. If nothing is drawn the compositor will continue to use the 
> buffer it acquired earlier.

I think you mean page flipping, not double buffering.

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.


On Thu, 3 Jan 2013, Gregg Tavares wrote:
>
> So I've been thinking more about this and I'm wondering, for the time 
> being, why have canvas.setContext and why expose the 
> Canvas2DRenderingContext constructor?

Well the constructor is needed so that there's a way to do an entirely 
off-screen bitmap, for when you just want to do some image work that isn't 
going to be displayed.

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).


> That means we can solve the 1 context multiple canvases issue later 
> making this a minimal api change?

I thought the "1 context multiple canvases issue" was a higher priority 
than the "canvas on workers" issue. Is this wrong?


> 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.

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