Re: [whatwg] Canvas in workers

On Sun, Oct 13, 2013 at 12:12 PM, Glenn Maynard <glenn@zewt.org> wrote:

>  On Sat, Oct 12, 2013 at 11:12 PM, Kyle Huey <me@kylehuey.com> wrote:
>
> >    1. Rename CanvasProxy to WorkerCanvas and only allow it to be
> >    transferred to workers.  I don't think we're interested in supporting
> >    cross-origin <canvas> via CanvasProxy (I would be curious to hear more
> >    about what the use cases are).
> >
>
> You can transfer data to a worker that's cross-origin, if you have a
> MessagePort where the other side goes to another origin's worker (possibly
> given to you via eg. window.postMessage).
>
> Is the real goal here trying to limit this to threads and avoid IPC, or is
> this actually a cross-origin concern?
>

Basically it's simpler to have CanvasProxy/WorkerCanvas only supported on
workers. Cross-origin isn't itself a concern.


>    2. Add a worker-only WorkerCanvas constructor that takes the desired
> >    width/height of the drawing surface.
> >
>
> This looks like it's trying to allow entirely off-screen rendering within a
> Worker, which is fine, but there's no way to resize the backing store in
> this mode.
>

We don't have a use-case for resizing the backing store of a worker-created
canvas.

> simply draw in a loop without yielding.  To solve this, if commit is
> called
> > and the current dimensions on the main thread don't match the dimensions
> of
> > the WorkerCanvas it would fail (return false) and update the dimensions
> of
> > the WorkerCanvas before returning.  This is technically a violation of
> > run-to-completion semantics, but is needed to support workers that do not
> > yield.
> >
>
> This sounds like it's easy to get wrong, since it'll probably be rare.  An
> exception might be better, so if you don't handle it you at least get an
> error logged to the console.
>

Sure, that's probably better.

There will be flicker issues with this.  The canvas is cleared when you
> change width or height.  In the UI thread that's OK, since the author can
> synchronously redraw immediately after changing the size.  Here, it's
> likely it won't be redrawn in time, so it'll flicker whenever the size
> changes, especially if it's being changed smoothly.  Here's a suggestion to
> fix this:
>
> - When the UI thread changes Canvas.width or Canvas.height, it doesn't
> actually resize buffers.  Instead, it sends a message to the WorkerCanvas
> asking for the change.  Until the change actually happens, the Canvas
> continues to be composited as before.  (However, the change to .width and
> .height is visible on the object immediately.)
> - When the WorkerCanvas's event loop receives a message asking for a size
> change:
>   - Change the size of the back-buffer, and update WorkerCanvas.width and
> WorkerCanvas.height accordingly.
>   - Fire onresize on the WorkerCanvas.  The worker is expected to redraw
> here.  (This is where the "implicit commit" matters: we want to guarantee a
> commit here.)
>   - Only when the newly-redrawn buffer is committed does the front buffer's
> size get updated to match the back-buffer.
>
> In other words, when you change the size in the UI thread, it continues to
> composite the same image (possibly not filling the whole element, or being
> stretched) until the worker actually gets the resize and has a chance to
> redraw it.
>
> This also means the idea of not being able to commit because of a resize
> can go away, and commit() can be void, since the back-buffer size never
> actually changes while the worker is drawing.
>

There is the slight problem that changing both width and height would fire
two events.

A bigger problem is that your approach isn't compatible with a worker that
draws frames in a loop without yielding. I'm uncertain how important that
is, so I'll wait for Kyle to address that.

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 Sunday, 13 October 2013 21:43:19 UTC