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

Re: [whatwg] Counterproposal for canvas in workers

From: Rik Cabanier <cabanier@gmail.com>
Date: Thu, 17 Oct 2013 13:35:19 -0700
Message-ID: <CAGN7qDDMv6wnxZao6r5Yoc2meTAbXNuKC8315+xz4+Umkv=cJg@mail.gmail.com>
To: "Robert O'Callahan" <robert@ocallahan.org>
Cc: "whatwg@whatwg.org" <whatwg@whatwg.org>
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.

Every task would start with a 'clean' graphics state. We could define ways
to pass other canvas contexts into a task. Those other contexts could even
be drawn in other tasks (so you could use them while they are being drawn)

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

No. Every task acts like a unique canvas context; there's no sharing of
I'm unsure how this would work for WebGL since I'm not all that familiar
with its architecture. However, it seems that the end result of a webgl
application, is a series of commands that are sent to the graphics chip. In
theory, this should be compatible.

> I don't think this supports a worker/task generating a steady stream of
> frames, e.g. for a 3D game. Does it?

It should. When the promise of a task if fulfilled, the main thread could
schedule another task. I think the scheduling should be done inside a
requestAnimationFrame for best performance.

Since there can only be 1 task with the same id active at a time, an author
could just continuously schedule tasks in requestAnimationFrame.
In that case if the tasks need to be synchronized, I think the author would
create 1 main task that generates subtasks to draw different parts of a
scene. Otherwise, there wouldn't be a "flush" to the screen since tasks
would be scheduled all the time.

> I'm not all that enthusiastic :-)

That's OK!
Received on Thursday, 17 October 2013 20:35:47 UTC

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