Re: [whatwg] Counterproposal for canvas in workers

On Fri, Oct 18, 2013 at 10:56 AM, Justin Novosad <junov@google.com> wrote:

> On Thu, Oct 17, 2013 at 5:50 PM, Rik Cabanier <cabanier@gmail.com> wrote:
>
>> Creating temporary canvases is still possible. I'm unsure how it would be
>> different from a worker.
>> An advantage would be that you can draw to the temporary canvases in
>> parallel to using them. Only PIXEL access is disallowed, you can still call
>> drawImage using a canvas that has outstanding tasks.
>>
>
> Right. The write-only restriction would only apply to canvas contexts that
> commit (push their tasks) directly down to the compositor. You could still
> create a canvas that is local to the worker, rasterize it in the worker and
> do readbacks in the worker, create ImageBitmaps from it, etc.
>

I'm not sure that you and Rik are talking about the same thing, since he's
still talking about "outstanding tasks". If you are talking about the same
thing, I don't know what it is. I'd like to see some concrete details for
what you'd change in the current WorkerCanvas proposal. For the sake of
clarity I've put (my understand of) it here:
https://wiki.mozilla.org/User:Roc/WorkerCanvasProposal

With WorkerCanvas and transferToImageBitmap, you can draw multiple layers
in parallel (and actually draw, not just queue drawing commands) by
creating multiple workers, having them each produce an ImageBitmap, and
compositing those ImageBitmaps together by stacking <img> elements or
drawing them all to a single canvas. It uses more memory but you get more
parallelism.

In fact, an implementation could choose to take the deferred-drawing
approach instead. You would queue up drawing commands in the WorkerCanvas
(or the drawing context), and then transferToImageBitmap would not
immediately render but produce an ImageBitmap implementation encapsulating
the list of drawing commands to be drawn later, wherever/whenever that
ImageBitmap ended up being used. I think for commit() the implementation
would always want to force rasterization on the worker (or possibly some
dedicated canvas-rendering thread); you could forward a list of drawing
commands to the compositor thread for rasterization but I don't think
there's any reason to do that (and some good reasons not to).

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 23:02:24 UTC