[whatwg] Canvas in Workers

[Gregg Tavares]

On Tue, Jan 8, 2013 at 11:12 AM, Ian Hickson <ian at hixie.ch> wrote:

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

How would you choose flip vs copy with just commit?

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 });

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 });



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

Agreed but that's a separate problem

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


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


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

I don't know if it's higher priority. It seemed to inform the worker
related design so it was important to look at.


>
>
> > 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. The whole setContext vs
DrawingBuffer etc stuff seems possibly orthogonal to the issue of rendering
to a canvas from a worker. 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. Since Canvas already is what it is, any solution for single context
multiple canvases has to work with Canvas. So adding a new object,
CanvasProxy, which is really just a representation for Canvas with the same
API doesn't seem like it adds any new issues.



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