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

On Mon, Mar 11, 2013 at 10:58 PM, Rik Cabanier <cabanier@gmail.com> wrote:

> 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.
>

Only if the source of the ImageBuffer is something the script doesn't have
access to read, not if it's from a Blob or a same-origin HTMLImageElement.

Currently, ImageBitmap only supports same-origin images and untainted
canvases.  This looks like one of those cases where cross-origin support is
being held back until implementations are handling the basic
non-cross-origin functionality.

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's what copy-on-write is for, so a copy wouldn't have to be made unless
the data actually changes.  As Boris says, this is the case regardless of
whether the ImageData was originally created with a deep copy or not.

Whether copy-on-write ArrayBuffers can be efficiently implemented has come
up in the past, but I don't know if there's a solid answer.  It might
require some intelligence on the part of the JS engine, eg. to pull the "do
I need to make a copy?"-logic out of inner loops so it doesn't add overhead
to every write, or to set up write-protection flags on the buffer to
receive a signal if a write happens.

(I suppose a simpler optimization is simply copy-on-access: make a copy of
the backing store if the .data property of ImageData is accessed.  That's
not as nice, but it would optimize a lot of cases without needing anything
so low level.)

-- 
Glenn Maynard

Received on Tuesday, 12 March 2013 04:56:36 UTC