[whatwg] Counterproposal for canvas in workers
cabanier at gmail.com
Thu Oct 17 13:36:49 PDT 2013
On Thu, Oct 17, 2013 at 10:57 AM, Justin Novosad <junov at google.com> wrote:
> 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.
That is basically what I'm proposing, except that the "commit" is a return
for the task.
Continually drawing in a worker seems like it would suck up a lot of power
and cpu resources...
> 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
>> > with promises. A task is considered "done" if it exits and all its
>> > are fulfilled.
>> It seems that tasks are like workers, but different, and you'd have to do
>> lot of extra work to precisely define the execution environment of the
>> 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
>> 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 :-)
>> 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
>> stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg
>> 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp
>> waanndt wyeonut thoo mken.o w *
More information about the whatwg