On Wed, Oct 16, 2013 at 10:26 PM, Robert O'Callahan <rob...@ocallahan.org>wrote:
> On Thu, Oct 17, 2013 at 3:34 PM, Rik Cabanier <caban...@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 state. 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!