Re: [whatwg] Canvas in workers

On Sat, Oct 19, 2013 at 1:28 AM, Glenn Maynard <glenn@zewt.org> wrote:

> I'd like to hear thoughts on the "context.attachToCanvas" approach.  I
> think it has important advantages over ImageBitmap:
>
> - ImageBitmap requires the user to call close().  If the user forgets, or
> doesn't know, or misses it in some code paths, the problems caused aren't
> obvious.  Worse, they may only appear in some implementations and not
> others, depending on GC strategies.  attachToCanvas doesn't need cleanup in
> the first place, which is a nicer solution--there's nothing for the user to
> get wrong.
>

It's not clear to me how attachToCanvas works. An application like Google
Maps wants to draw to multiple canvases from a worker and then render the
updated canvas contents all at once, in synchrony with changes to the DOM
made by the main thread. How would you do that with attachToCanvas?


> - If you're rendering in a worker and the eventual target is in the main
> thread, the worker needs to be careful to not start rendering again until
> the main thread has assigned the ImageBitmap to where it wants it, and
> called .close().  You'd need to send a message back to the worker going
> "okay, you can continue now".  Otherwise, you'd start rendering before a
> buffer has been freed up for reuse, and end up creating more backbuffers
> than you intended (which matters for large screens).  This seems easy to
> get wrong, and attachToCanvas doesn't have this problem.
>

Not if you use transferToImageBitmap.


> - With ImageBitmap, you need to create a helper canvas, then each time you
> render to a new target, you need to resize the canvas to match where it'll
> eventually go, so the resulting ImageBitmap is the size of its
> destination.  (This may also need to be carefully optimized, so the
> implementation doesn't actually resize the backing store every time its
> size changes.)  With attachToCanvas, you just size both canvases normally
> once, and switch between them with a single function call.
>

I'm not sure how helpful this is. In the case of WebGL, the rendering
context has resources that need to be sized the same as the destination
color buffer, so they'll need to be resized anyway if you're actually using
a single context to render to canvases of different sizes. My guess is that
the advice will always be "don't do that".

- attachToCanvas matches the way Canvas works today: you create a Canvas,
> put it in the document (if it's for display), and render to it.  For two
> canvases, you'd just add a second Canvas, and toggle as needed.  With
> ImageBitmap, you have to restructure everything as soon as you want a
> second canvas, since you'd want to have a single offscreen Canvas for
> rendering, and to have <img> elements in the document instead of canvases.
>

I believe these are minor changes, especially compared to moving drawing to
a worker.

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 Saturday, 19 October 2013 15:11:54 UTC