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

Re: [whatwg] Canvas in workers

From: Robert O'Callahan <robert@ocallahan.org>
Date: Wed, 16 Oct 2013 11:11:15 +1300
Message-ID: <CAOp6jLb3j0U5-kqfyh3W_ZHXdXos4pEwcVkb-gZ+_-g=cL7aqg@mail.gmail.com>
To: Justin Novosad <junov@google.com>
Cc: WHAT Working Group <whatwg@whatwg.org>, Kyle Huey <me@kylehuey.com>, Kenneth Russell <kbr@google.com>
On Wed, Oct 16, 2013 at 10:06 AM, Justin Novosad <junov@google.com> wrote:

> If we put that idea into the WorkerCanvas proposal, here is an idea of how
> commits could handle resizes asynchronously:
>
> 1) Main thread executes some JS that changes the size of the canvas, and
> posts an event to the Worker in order to propagate the change to the
> WorkerCanvas.
> 2) On the worker thread, the WorkerCanvas stores the new size, but does not
> apply it right away to avoid resetting canvas contents mid frame.
> 3) commit() is called on the WorkerCanvas, causing the current canvas
> contents to be sent to the main thread for display, and the new canvas size
> comes into effect (lazily?)
> 4) The main thread receives the committed pixels. N.B.: The size of the
> received buffer does not match canvas element's intrinsic size
> 5) At paint time, the canvas contents get displayed respecting the canvas
> element's current size. The mismatched pixel buffer is either
> streched/squashed or clipped/padded to fit.
>

Step 5 has an issue that different apps might want to make different
choices about whether and how to scale/pad/crop. But I think here we can
leverage CSS3 object-fit and object-position properties:
http://dev.w3.org/csswg/css-images-3/#object-fit
Let's make those apply to <canvas>, where the "replaced content" is the
canvas backing store!

Then we would modify your proposal a little bit. Let's say that the main
thread cannot modify the canvas buffer size after the canvas has been
transferred. If you want to change the buffer size, you'll have to
postMessage your worker and have it update the buffer size. When the worker
commits a canvas buffer with a size that doesn't match the element size,
object-fit and object-position are consulted to determine what gets
rendered. Those values can be sent to the compositor, so we can always
render the right thing.

This means a worker constantly producing frames without yielding can't be
notified of a buffer size change, but I don't think that's a big deal.

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 Tuesday, 15 October 2013 22:11:41 UTC

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