W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2013

Re: [whatwg] Counterproposal for canvas in workers

From: Kenneth Russell <kbr@google.com>
Date: Thu, 17 Oct 2013 14:03:48 -0700
Message-ID: <CAMYvS2dpx9_sZ4NC135rT92DBmPNWtiGeBML0kKQ6oSsV4-QBg@mail.gmail.com>
To: "Robert O'Callahan" <robert@ocallahan.org>
Cc: "whatwg@whatwg.org" <whatwg@whatwg.org>, Rik Cabanier <cabanier@gmail.com>
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.

-Ken
Received on Thursday, 17 October 2013 21:04:13 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:12 UTC