[whatwg] Canvas 2D memory management

[Paul Bakaus]

Hi Ashley,

I brought this very topic up in the latest W3C performance workgroup
meeting but pretty much all of my ideas were cut off due to a number of
parties believing that these are ultimately UA-specific (browser specific)
concerns, and should be dealt with at the browser level.

Jason Weber of the IE team (cc'ed), in particular, was confident that IE
handling it sufficiently already. To his credits, I simply didn't try to
come up with a test case that proves otherwise, so I think that would be
the next step needed to convince vendors that this is a generic issue.
Maybe you can help?

In any case, here [1] are my slides from the meeting and here [2] is the
report from the workshop.

[1] 
https://docs.google.com/presentation/d/1a1NfQmRtuQYtBgfPVVHQBwWzDgmPaHASsyM
FWLwWMbI/edit#slide=id.p
[2] http://www.w3.org/2012/11/performance-workshop/report.html#i10

Thanks!
Paul

On 09.01.13 17:00, "Ashley Gullen" <ashley at scirra.com> 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 management
>issues.  Consider a device with 50mb of texture memory available.  A game
>might contain 100mb of texture assets, but only use a maximum of 30mb of
>them at a time (e.g. if there are three levels each using 30mb of
>different
>assets, and a menu that uses 10mb of assets).  This game ought to fit in
>memory at all times, but if a user agent is not smart about how image
>loading is handled, it could run out of memory.
>
>We have a WebGL renderer which solves this by explicitly creating and
>deleting textures as necessary when switching levels, which guarantees
>that
>memory is managed efficiently.  It also has the additional benefit that
>all
>necessary textures are pre-loaded, so there's no janking during the game
>as
>the first drawImage() of a particular asset in the level uploads a
>texture.
>
>I would like to suggest memory management features for the canvas 2D
>rendering context.  By explicitly pre-loading images and releasing them at
>the end of the level we can guarantee that devices will not run out of
>memory, as well as making gameplay smoother.
>
>Some ideas:
>1) add new functions to the canvas 2D context, such as:
>ctx.load(image): cache an image in memory so it can be immediately drawn
>when drawImage() is first used
>ctx.unload(image): release the image from memory
>
>2) we can drawImage() every image on startup to force lazy-loading
>browsers
>to load everything that will be used, but there's still no way to indicate
>which images should be released at the end of a level.  This could be left
>for the browser to determine (perhaps releasing by least-recently-used),
>but perhaps this should be required in the specification?
>
>3) leave current behavior as it is and suggest WebGL for this type of
>application
>
>My preference is option 1, but I don't know if this works for all use
>cases
>and will work nicely with implementations.  Any thoughts?
>
>Ashley Gullen
>Scirra.com