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

On Mon, Mar 11, 2013 at 9:56 PM, Glenn Maynard <glenn@zewt.org> wrote:

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

You're correct. I misread the IDL.


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


Maybe it could be implemented like weak maps?
The imagedata could keep a weak reference to the Uint8ClampedArray. If the
JS has no more references to the Uint8ClampedArray, the interpreter could
call to delete the array. At that point, the image data can be copied and
treated as read-only (until someone calls data again)

Received on Tuesday, 12 March 2013 05:22:42 UTC