On Tue, May 20, 2014 at 10:01 PM, Justin Novosad wrote:
> 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
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 e
On Sun, May 18, 2014 at 11:02 PM, Robert O'Callahan wrote:
> On Sat, May 17, 2014 at 4:18 AM, Anne van Kesteren wrote:
>
>> Maybe we should have .srcObject similar to what we're doing for
>> media elements. .src can simply return about:imagebitmap or some
>> such. That way you can also assign a Bl
On Sat, May 17, 2014 at 4:18 AM, Anne van Kesteren wrote:
> Maybe we should have .srcObject similar to what we're doing for
> media elements. .src can simply return about:imagebitmap or some
> such. That way you can also assign a Blob to an element without
> having to do the weird createObjectUR
On Fri, May 16, 2014 at 7:47 PM, Justin Novosad wrote:
> On Fri, May 9, 2014 at 5:51 PM, Ian Hickson wrote:
>> This is an interesting idea. I don't know what the state of the other
>> methods discussed here is (see my comment at the top of the e-mail cited
>> above). However, I've filed a bug for
On Fri, May 9, 2014 at 5:51 PM, Ian Hickson wrote:
> On Thu, 18 Jul 2013, Justin Novosad wrote:
>
> > However, one weakness of the current API is that upon construction of
> > the ImageBitmap, the browser does not know whether the asset will be
> > used with a GPU-accelerated rendering context or
On Thu, 18 Jul 2013, Justin Novosad wrote:
> On Thu, Jul 18, 2013 at 12:50 PM, Ian Hickson wrote:
> > On Wed, 9 Jan 2013, Ashley Gullen wrote:
> > >
> > > Some developers are starting to design large scale games using our
> > > HTML5 game engine, and we're finding we're running in to memory
> >
