Re: [whatwg] Counterproposal for canvas in workers

On Thu, Oct 17, 2013 at 2:08 PM, Rik Cabanier <cabanier@gmail.com> wrote:
>
>
>
> On Thu, Oct 17, 2013 at 2:03 PM, Kenneth Russell <kbr@google.com> wrote:
>>
>> On Wed, Oct 16, 2013 at 10:26 PM, Robert O'Callahan
>> <robert@ocallahan.org> wrote:
>> > On Thu, Oct 17, 2013 at 3:34 PM, Rik Cabanier <cabanier@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.

OK, I see. Sorry for misinterpreting.

It seems to me that this proposal would restrict even further what the
worker executing the task can do, and be harder to program to than the
existing worker model. I'm interested in pursuing the other discussion
around a WorkerCanvas rather than this one.

-Ken

Received on Thursday, 17 October 2013 21:14:59 UTC