Well, you could assign a unique sequential identifier or GUID to
ImageBitmaps, like object URLs, as long as you remove the lifetime
relationship where the object has to be manually freed. That would let
you do some of those caching scenarios, the key is that the lifetime
is now managed by 'do any elements use this ImageBitmap as a source,
or is it retained by user JS', I think?

On Tue, May 20, 2014 at 1:01 PM, Justin Novosad <ju...@google.com> wrote:
> On Sun, May 18, 2014 at 11:02 PM, Robert O'Callahan 
> <rob...@ocallahan.org>wrote:
>> On Sat, May 17, 2014 at 4:18 AM, Anne van Kesteren <ann...@annevk.nl>wrote:
>>> Maybe we should have <img>.srcObject similar to what we're doing for
>>> media elements. <img>.src can simply return about:imagebitmap or some
>>> such. That way you can also assign a Blob to an <img> element without
>>> having to do the weird createObjectURL() hack that might leak memory
>>> if you're not careful.
>> I like this approach, but I think it's simpler to continue to have
>> HTMLImageElement.src reflect the "src" content attribute.
>> I wonder what kind of broader effect it would have if image content can no
> longer be uniquely identified or retrieved using a URL. In many places in
> Blink/WebKit (and presumably other implementations as well) URLs are used
> as keys and handles for image resources. All of that would have to be
> refactored.

Reply via email to