W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2013

Re: [whatwg] Canvas 2D memory management

From: Rik Cabanier <cabanier@gmail.com>
Date: Sat, 12 Jan 2013 20:08:49 -0800
Message-ID: <CAGN7qDDhJ8xOywpKmCpgUKQZDSGmzz95KqSb=_N5YKW+pQUmCg@mail.gmail.com>
To: Ashley Gullen <ashley@scirra.com>
Cc: "whatwg@lists.whatwg.org" <whatwg@lists.whatwg.org>, pbakaus@zynga.com, jweber@microsoft.com, robert@ocallahan.org
On Sat, Jan 12, 2013 at 11:52 AM, Ashley Gullen <ashley@scirra.com> wrote:

> I'd be curious to learn more about how IE handles it.  Does it use
> least-recently-used or some other heuristics?  I think letting the browser
> guess could result in sub-optimal load times.  Consider a game with two
> levels:
> Level 1: uses texture set A and B
> Level 2: uses texture set A and C
> When switching from level 1 to level 2, we want to release texture set B
> then load texture set C, leaving set A in memory.  If the browser guesses
> about releasing textures, it may release textures from set A while loading
> set C, when it would be more appropriate to release textures from set B.
>  Since level 2 still needs set A, it will load them again.  This means
> either the game still janks during level 2, or when loading textures from
> set A are needlessly released and loaded again, increasing the load time.
>
> I hadn't heard of ImageBitmap before, and it looks like it could solve the
> problem, assuming the existence of an ImageBitmap implies the texture is
> already loaded in memory (which it looks like the intent is).  If set A's
> ImageBitmap objects are still referenced, and set B are unreferenced and
> collected when loading set C if the device runs out of memory, that appears
> to be optimal behavior.
>

Well, it would be the optimal behavior if you knew for sure that A and (B
or c) would fit in the browser's memory without having to resort to paging.
Since you don't, you might still get worse janking (or outright failure)
than if you could give hints to the JS engine that certain things are OK to
be destroyed first. (This is probably a discussion for a JavaScript mailing
list and not whatwg.)


> What's the implementation status of ImageBitmap?  Do any browsers support
> it yet?
>

I believe noone has implemented it yet. I scanned the WebKit and Mozilla
code bases and didn't find any references.


>
>
> On 11 January 2013 22:56, Rik Cabanier <cabanier@gmail.com> wrote:
>
>>
>>
>> On Fri, Jan 11, 2013 at 2:36 PM, Robert O'Callahan <robert@ocallahan.org>wrote:
>>
>>> On Sat, Jan 12, 2013 at 6:41 AM, Rik Cabanier <cabanier@gmail.com>wrote:
>>>
>>>> Some of you concerns with memory management could be addressed with
>>>> WeakMaps.
>>>> Basically, you can put all your images in a WeakMap and during the draw
>>>> cycle, you pull them out and use them. If they're no longer there, it
>>>> meant
>>>> that the garbage collector has kicked in to free up memory and you need
>>>> to
>>>> reload (which will unfortunately cause a jank). I'm unsure how smart the
>>>> garbage collector is because you probably want the items in the
>>>> WeakMaps to
>>>> be deleted last.
>>>>
>>>
>>> WeakMaps don't work like that. You can only test whether something is in
>>> a WeakMap by looking it up with a key object. If the key object stays alive
>>> and the WeakMap stays alive, then the value must also stay alive. On other
>>> hand, if the key object or the WeakMap have been collected, obviously you
>>> can't do the lookup. So you can't observe whether GC has happened using a
>>> WeakMap. (This is by design.)
>>>
>>> Sorry about that!
>> yes, you are correct that you can't use it that way.
>>
>> Someone told me that WeakMaps work the same way as Flash's dictionary
>> with weak keys, but that is not the case.
>>
>> FWIW, flash game developers use dictionaries with 'weak keys' as I
>> described earlier. If the memory runs low, the garbage collector will
>> delete objects from that cache.
>>
>
>
Received on Sunday, 13 January 2013 04:09:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:12 GMT