W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2013

Re: [whatwg] Canvas in workers

From: Robert O'Callahan <robert@ocallahan.org>
Date: Mon, 21 Oct 2013 06:47:42 +0200
Message-ID: <CAOp6jLY4Dceg5R0AyNkezR2dMHa4qbokg8CN5tHKYqR+E=pv5Q@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: WHAT Working Group <whatwg@whatwg.org>, Kyle Huey <me@kylehuey.com>, Kenneth Russell <kbr@google.com>
On Sun, Oct 20, 2013 at 5:29 PM, Glenn Maynard <glenn@zewt.org> wrote:

> That's not the problem attachToCanvas tries to solve.  It tries to solve
> rendering to multiple canvases, without requiring synchronization with the
> UI thread.  I have a proposal for handling synchronization with DOM
> updates, but I'll post it in a separate thread.
>

OK.


>   - 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.
>
> transferToImageBitmap does have this problem.  If you transferToImageBitmap
> to detach your backing store to display it somewhere, then start rendering
> the next frame without waiting for the ImageBitmap to be given to the
> target, then as soon as you start rendering you'll end up creating a 3rd
> rendering buffer.
>

OK.

If you think that a single context outputting to multiple canvases
> fundamentally won't work well with canvases of different sizes, then forget
> about the feature.
>
> When you attachToCanvas, you're attaching that canvas's rendering buffer,
> not just its color buffer.  In WebGL terms, each canvas is a Framebuffer,
> with all its associated Renderbuffers.  Attaching the context to a canvas
> is like using bindFramebuffer to render to its backing store.
>

This is actually a disadvantage for attachToCanvas in some situations. If I
just want to generate N different rendered images (of the same size) (e.g.
http://www.turbosquid.com/Search/3D-Models/Vehicle/Car), the only thing I
want N of is the final color buffer.

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 Monday, 21 October 2013 04:48:05 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:12 UTC