[whatwg] Counterproposal for canvas in workers

[Justin Novosad]

Here is similar concept, but with an API more like WokerCanvas:
The CanvasRenderingContext2D associated with a WorkerCanvas would only
record draw commands, without executing them. The context would be
write-only. When you call commit on the WorkerCanvas, the block of recorded
draw commands would be posted back to the main thread or directly to the
compositor.  What I like about this approach is that it is always just
pushing data downstream, thus eliminating buffer synchronization issues as
well as the need for double buffering canvas backing stores.


On Thu, Oct 17, 2013 at 1:26 AM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Thu, Oct 17, 2013 at 3:34 PM, Rik Cabanier <cabanier at 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 :-)
>
> Rob
> --
> Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
> le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
> stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
> 'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
> waanndt  wyeonut  thoo mken.o w  *
> *
>