Re: [whatwg] Counterproposal for canvas in workers

I think most of these have been said already, but my issues with (my
understand of?) this proposal are:

1. It requires defining a new script execution environment different from
both the main thread and workers.  That seems like a lot of unnecessary
work.  And this execution environment is either going to duplicate much of
web workers or it will lack a lot of functionality that people want.
2. It is mostly stateless, requiring any global one time setup to happen
per task.  But it also maintains a relatively heavy amount of state (a
script execution environment and global object for each task on each
canvas) which will persist for the lifetime of the canvas.  Executing a
"drawSplashScreen" task at the beginning of a long-running game means you
would carry that task's memory overhead for the entire game.  Developers
won't actually want to do that so they'll either have to segregate tasks
onto different canvases based on task lifetime or they will have to limit
the number of tasks they use.
3. 'synchronized' false seems pretty useless.  When would it be useful to
execute a bunch of tasks out of order and update the screen whenever any of
them finish?  You would have essentially no guarantees on what appears on
screen.
4. I'm not sure whether these tasks are intended to be spawned from the
main thread or from a worker thread.  If the former, this proposal does not
solve the "render things without waiting on the main thread at all" goal.
If the latter, it's unclear how synchronization with main thread DOM
updates works.

It seems like we're getting towards consensus on the other thread.  I would
prefer to drag that proposal over the finish line since this will require a
lot more work.

- Kyle

Received on Monday, 21 October 2013 02:10:25 UTC