[whatwg] Counterproposal for canvas in workers

[Rik Cabanier]

On Thu, Oct 17, 2013 at 2:03 PM, Kenneth Russell <kbr at google.com> wrote:

> On Wed, Oct 16, 2013 at 10:26 PM, Robert O'Callahan
> <robert at ocallahan.org> wrote:
> > On Thu, Oct 17, 2013 at 3:34 PM, Rik Cabanier <cabanier at gmail.com>
> wrote:
> >
> >> The tasks themselves can also launch synchronized/unsynchronized
> subtasks
> >> with promises. A task is considered "done" if it exits and all its
> promises
> >> are fulfilled.
> >>
> >
> > It seems that tasks are like workers, but different, and you'd have to
> do a
> > lot of extra work to precisely define the execution environment of the
> task
> > script.
> >
> > It also seems that you have to precisely define how different tasks
> > interact. For example is the current path left in the canvas by task 1
> > usable by the code in task 2? You also have to define how this works in
> > WebGL.
> >
> > I don't think this supports a worker/task generating a steady stream of
> > frames, e.g. for a 3D game. Does it?
> >
> > I'm not all that enthusiastic :-)
>
> Sorry, neither am I. OpenGL (and WebGL) applications do a lot of
> one-time setup, and then repeatedly redraw using the previously
> uploaded objects. This "stateless" drawing model isn't compatible with
> that structure.
>

Every task per ID and per canvas has access to its own state/VM.
So, the first time a task is executed (or we could provide an 'init'
phase), it could do setup which will be maintained between tasks.