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

Re: [whatwg] Proposal: ImageData constructor or factory method with preexisting data

From: Glenn Maynard <glenn@zewt.org>
Date: Mon, 11 Mar 2013 22:27:33 -0500
Message-ID: <CABirCh9hXurkb3es9Ow3boy7dpH87+bf+Qe-yrmHkGiS+RR1Hw@mail.gmail.com>
To: Justin Novosad <junov@chromium.org>
Cc: WHAT Working Group <whatwg@whatwg.org>, Kenneth Russell <kbr@google.com>, Rik Cabanier <cabanier@gmail.com>
On Mon, Mar 11, 2013 at 9:48 PM, Justin Novosad <junov@chromium.org> wrote:

> The use cases I see for this new interface is for relaying image data, that
is *not* generated in JS.  For example, suppose a chunk of image data is
>  generated on the server side and sent to the client via WebSocket. On the
> client side, you just want to copy the data field of the message event onto
> a 2D canvas. With the current API, an intermediate copy is required in
> order to wrap the incoming data into an ImageData object.

If data is generated server-side, then the createImageBitmap API is
probably what you want.

If there are use cases for creating an ImageData, I recommend not making a
copy, so all this is doing is taking an existing ArrayBuffer and creating a
thin wrapper around the same buffer.

That said, avoiding an extra copy for data that just came in over the
network doesn't seem like much of an optimization (and it's probably
compressed anyway), and if copy semantics are wanted, unnecessary copies
can still be avoided with copy-on-write.

Glenn Maynard
Received on Tuesday, 12 March 2013 03:27:58 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:20 UTC