W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2015

Re: [whatwg] Canvas image to blob/dataurl within Worker

From: Robert O'Callahan <robert@ocallahan.org>
Date: Thu, 26 Mar 2015 09:28:10 +1300
Message-ID: <CAOp6jLb3aYfbeXdDpG7SMFmn6sDr-qM=fFaXYwk=YaTHx9XMaw@mail.gmail.com>
To: Justin Novosad <junov@google.com>
Cc: Ian Hickson <ian@hixie.ch>, Kenneth Russell <kbr@google.com>, Jake Archibald <jaffathecake@gmail.com>, WHATWG <whatwg@whatwg.org>
On Thu, Mar 26, 2015 at 8:40 AM, Justin Novosad <junov@google.com> wrote:

> One idea we've been brewing that has not surfaced on this thread so far is
> that of having an ImageBitmap.toBlob(), which would return a Promise. Also,
> ImageBitmap should be transferable. This idea is just partially baked right
> now, but I wanted to throw it out into the open to get people thinking
> about it. The rationale behind this is that ImageBitmap is basically a
> lightweight read-only proxy for pretty much anything that can be used as an
> image source. So this single API entry-point can perform as well as a
> direct toBlob() method hanging off of any other type of object that an
> ImageBitmap can be created from. Because it is an opaque and immutable
> object, it gives browser vendors a lot of latitude for implementing high
> performance code paths. It allows pixel data from the DOM to cross Worker
> boundaries without making copies (at least in cases where the source is a
> static image). It allows interactions with blob storage to be driven from a
> worker (vs. canvas.toBlob), hence avoiding jank on the main thread. Raw
> image data generated in JS would not have to transit through a canvas (just
> create an ImageBitmap from an ImageData object), which eliminates a lot of
> unnecessary pixel pushing.


That makes sense to me.

If we do that, and also add HTMLCanvasElement.transferToImageBitmap, then
one-shot "draw into a canvas and create a blob" applications could have
really minimal memory usage. That method would detach the backbuffer and
clear the canvas (which I think all browsers are optimizing to "no
backbuffer").

Eliminating the transit through canvas also
> allows for fast paths for capturing blobs from <video>, <img>, svg, URLs,
> to name a few.
>

With new APIs on those elements, you mean?

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.
Received on Wednesday, 25 March 2015 20:28:36 UTC

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