[whatwg] Canvas in workers
robert at ocallahan.org
Tue Oct 15 16:41:59 PDT 2013
On Wed, Oct 16, 2013 at 11:55 AM, Kenneth Russell <kbr at google.com> wrote:
> On Mon, Oct 14, 2013 at 1:34 PM, Robert O'Callahan <robert at ocallahan.org>
> > On Mon, Oct 14, 2013 at 2:20 PM, Kenneth Russell <kbr at 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
> > DrawingBuffer layer of abstraction seems unnecessarily complex, and it
> > doesn't handle direct presentation of frames from the worker, bypassing
> > 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
> 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?
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 *
More information about the whatwg