- From: Rik Cabanier <cabanier@gmail.com>
- Date: Mon, 11 Mar 2013 20:58:37 -0700
- To: Glenn Maynard <glenn@zewt.org>
- Cc: WHAT Working Group <whatwg@whatwg.org>, Kenneth Russell <kbr@google.com>, Justin Novosad <junov@chromium.org>
On Mon, Mar 11, 2013 at 8:27 PM, Glenn Maynard <glenn@zewt.org> wrote: > 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. > http://www.whatwg.org/specs/web-apps/current-work/#imagebitmap > That would have the added benefit of having CORS. Drawing with a generic data buffer should probably taint the canvas state. > > 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. > I think that would make implementations that defer rendering much more complex and slower. (It would force putImage to execute immediately since it doesn't know if the buffer will change in JS) > > 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. > I agree. It seems better if you use a real image for file transfer since you will get better network throughput and you can store it compressed in memory.
Received on Tuesday, 12 March 2013 03:59:05 UTC