Re: [whatwg] Canvas in workers

On Wed, Oct 16, 2013 at 11:55 AM, Kenneth Russell <kbr@google.com> wrote:

> On Mon, Oct 14, 2013 at 1:34 PM, Robert O'Callahan <robert@ocallahan.org>
> wrote:
> > On Mon, Oct 14, 2013 at 2:20 PM, Kenneth Russell <kbr@google.com> wrote:
> >>
> >> Would you mind looking at the proposal
> >> http://wiki.whatwg.org/wiki/CanvasInWorkers and commenting on it?
> >
> >
> > Sure. Kyle and I looked at it while we were working on our proposal. The
> > main issues I have with it are that rearchitecting <canvas> to introduce
> the
> > DrawingBuffer layer of abstraction seems unnecessarily complex, and it
> > doesn't handle direct presentation of frames from the worker, bypassing
> the
> > main thread.
>
> Note that the CanvasInWorkers draft solves some other longstanding
> issues not addressed by the WorkerCanvas proposal. It provides the
> ability to render to multiple canvases from a single context, whether
> workers are involved or not.


That may be a useful feature, but I'd like to see it justified in its own
right.


> It achieves ideal memory utilization by
> being very explicit in the API, without the need for extensive and
> subtle optimizations behind the scenes.
>

We can be more explicit with ImageBitmaps. We could provide
WorkerCanvas.transferToImageBitmap which transfers the current canvas
contents to an ImageBitmap and clears the canvas. (Canvas implementations
are already optimized to support a zero-cost "cleared" state, because
existing benchmarks require it.) Sharing ImageBitmap contents across
threads during structured clone is not subtle. We can add an
HTMLImageElement.srcObject attribute which could take a Blob or an
ImageBitmap to enable explicit zero-copy rendering of ImageBitmaps. Would
that be explicit enough for you?

Personally I think high-performance manipulation of ImageBitmaps would be
more generally useful than detachable DrawingBuffers, and would be easier
for authors to understand.

If you squint, WorkerCanvas.transferToImageBitmap is similar to detaching a
DrawingBuffer. But I don't see a need to reattach a buffer to a canvas for
further drawing. Do you?

It's worth considering whether a change to the CanvasInWorkers
> proposal could support presenting frames directly from the worker.
>

Sure, by adding a commit() method to DrawingBuffer. Right?

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 23:42:23 UTC