[whatwg] Counterproposal for canvas in workers

[Rik Cabanier]

On Sun, Oct 20, 2013 at 7:09 PM, Kyle Huey <me at kylehuey.com> wrote:

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

Why would that be a lot of work? It would be almost identical to a worker
environment if not the same apart from some extra interfaces.


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

True, tasks will be carried around by the canvas that created them. I don't
understand why this would be harder than manually managing the state. Could
you not manage this per task?
(A 'detroyTask' function would cover this too)


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

I had the page that Ken pointed to in mind:
http://www.turbosquid.com/Search/3D-Models/Vehicle/Car
What if you're drawing a bunch of complex models to 1 canvas where you know
that each result is in a separate location? (Could also be used for sprite
sheets)


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

both.
I think I went over how the synchronization works in earlier emails.
Basically in a task, everything is queued so if you fire a task B in task
A, all the operations of task B will be inserted atomically in the right
location. (My naive polyfill doesn't do this yet but it would be easy to
implement)


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

I don't think it does require a lot more work (although people seem to
disagree).
This is a model that covers the following:
- drawing is synchronized with the main thread (Glenn started this as a new
thread)
- you can use APIs that are resticted for workers (such as text) in a task
- you can use content while is not constructed yet
- you can draw to the same canvas from multiple threads
- no need for triple buffering
- transparent for the author (No need to create workers or figure out how
many workers is optimal. No complicated message passing. No need to change
your use of canvas apart from reading pixels which they shouldn't do for
perf anyway)

Even if my proposal doesn't go anywhere (and it certainly looks like that
:-) ); it will highlight possible issues that need to be addressed or
limitations that authors will have to work around.