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

Re: [whatwg] Canvas in workers

From: Kenneth Russell <kbr@google.com>
Date: Wed, 16 Oct 2013 10:35:37 -0700
Message-ID: <CAMYvS2em1SzhWUjL32oeN6FvXrU6k+A5HeiV1ACDb5AwEGU3VA@mail.gmail.com>
To: Justin Novosad <junov@google.com>
Cc: WHAT Working Group <whatwg@whatwg.org>, Kyle Huey <me@kylehuey.com>, Robert O'Callahan <robert@ocallahan.org>
On Wed, Oct 16, 2013 at 5:39 AM, Justin Novosad <junov@google.com> wrote:
> On Tue, Oct 15, 2013 at 8:30 PM, Kenneth Russell <kbr@google.com> wrote:
>>
>> On Tue, Oct 15, 2013 at 4:41 PM, Robert O'Callahan <robert@ocallahan.org>
>> wrote:
>> > 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?
>>
>> Not immediately. The ability to transfer out the canvas's contents,
>> and render them in an HTMLImageElement without incurring an extra
>> blit, should address the Maps team's requirements.
>
>
> WorkerCanvas.copyToImageBitmap could be just as effective with a proper lazy
> copy-on-write mechanism. It would offer the same performance in cases where
> you would just need to transfer (as opposed to copy) the buffer, with the
> added flexibility that it reattaches a new buffer to the canvas, only if
> needed (at next draw).  Also the lazy copy can be skipped if the next draw
> operation to the canvas context is a clear, in which case the UA only needs
> to attach an uninitialized buffer.

I'm assuming that transferToImageBitmap will attach a new buffer to
the canvas as well. The semantic would be that the color buffer of the
canvas gets transferred to the ImageBitmap, and the canvas gets a new,
blank color buffer. (Any auxiliary buffers, like a depth buffer, would
also be implicitly cleared.)

It's easier to understand how to make the transfer operation efficient
than how to optimize the copy-on-write, which requires deeper analysis
of the calls made against the canvas and context in order to get peak
performance. If both are present then both the createImageBitmap and
transfer implementations can be really simple. Do you have a
particular objection to including the transfer API?

> Also, because ImageBitmaps are immutable objects, the API should probably be
> more like var imageBitmap = createImageBitmap(myWorkerCanvas);

Yes, right. That factory method is already spec'ed on the
WorkerGlobalScope [1]. It actually returns a Promise, so presumably
transferToImageBitmap would have to as well.

[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#imagebitmapfactories

-Ken
Received on Wednesday, 16 October 2013 17:36:04 UTC

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