W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2014

Re: [whatwg] ImageBitmap feature requests

From: K. Gadd <kg@luminance.org>
Date: Tue, 20 May 2014 19:41:06 -0700
Message-ID: <CAPJwq3Wj0NXkn-RpwvAEwPOrpWBS9L0mQxhE+BEDdL4mSK-hQg@mail.gmail.com>
To: Justin Novosad <junov@google.com>
Cc: "whatwg@whatwg.org" <whatwg@whatwg.org>, Ian Hickson <ian@hixie.ch>, Robert O'Callahan <robert@ocallahan.org>
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 <junov@google.com> wrote:
> On Sun, May 18, 2014 at 11:02 PM, Robert O'Callahan <robert@ocallahan.org>wrote:
>
>> On Sat, May 17, 2014 at 4:18 AM, Anne van Kesteren <annevk@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.
Received on Wednesday, 21 May 2014 02:42:12 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:20 UTC