Re: [whatwg] Counterproposal for canvas in workers

On Thu, Oct 17, 2013 at 10:57 AM, Justin Novosad <junov@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@ocallahan.org>wrote:
>
>> On Thu, Oct 17, 2013 at 3:34 PM, Rik Cabanier <cabanier@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  *
>> *
>>
>
>

Received on Thursday, 17 October 2013 20:37:20 UTC