[whatwg] Canvas 2D memory management

[K. Gadd]

Some of my applications would definitely benefit from this as well. A port
of one client's game managed to hit around 1GB of backing store/bitmap data
combined when preloading all their image assets using <img>. Even though
browsers then discard the bitmap data, it made it difficult to get things
running without killing a tab due to hitting a memory limit temporarily.
(The assets were not all in use at once, so the actual usage while playing
is fine). Having explicit control over whether bitmaps are resident in
memory would be great for this use case since I can preload the actual file
over the network, then do the actual async forced decode by creating an
ImageBitmap from a Blob, and discard it when the pixel data is no longer
needed (the game already has this information since it uses the C#
IDisposable pattern, where resources are disposed after use)


On Fri, Jul 19, 2013 at 12:34 PM, Justin Novosad <junov at google.com> wrote:

> On Fri, Jul 19, 2013 at 7:09 AM, Ashley Gullen <ashley at scirra.com> wrote:
>
> > FWIW, imageBitmap.discard() wouldn't be unprecedented - WebGL allows you
> to
> > explicitly release memory with deleteTexture() rather than letting the GC
> > collect unused textures.
> >
> >
> A related issue we have now is with canvas backing stores. It is common for
> web apps to create temporary canvases to do some offscreen rendering. When
> the temporary canvas goes out of scope, it continues to consume RAM or GPU
> memory until it is garbage collected. Occasionally this results in
> memory-leak-like symptoms.  The usual workaround is to use a single
> persistent global canvas for offscreen work instead of temporary ones
> (yuck).  This could be handled in a cleaner way if there were a .discard()
> method on canvases elements too.
>
>
> > Ashley
> >
> >
> >
> > On 18 July 2013 17:50, Ian Hickson <ian at hixie.ch> 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 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.
> > > >
> > > > [...]
> > > >
> > > > 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
> > >
> > > The Web API tries to use garbage collection for this; the idea being
> that
> > > you load the images you need when you need them, then discard then when
> > > you're done, and the memory gets reclaimed when possible.
> > >
> > > We could introduce a mechanism to flush ImageBitmap objects more
> > forcibly,
> > > e.g. imageBitmap.discard(). This would be a pretty new thing, though.
> Are
> > > there any browser vendors who have opinions about this?
> > >
> > > We should probably wait to see if people are able to use ImageBitmap
> with
> > > garbage collection first. Note, though, that ImageBitmap doesn't really
> > > add anything you couldn't do with <img> before, in the non-Worker case.
> > > That is, you could just create <img> elements then lose references to
> > them
> > > when you wanted them GC'ed; if that isn't working today, I don't see
> why
> > > it would start working with ImageBitmap.
> > >
> > > --
> > > Ian Hickson               U+1047E                )\._.,--....,'``.
>  fL
> > > http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._
> ,.
> > > Things that are impossible just take longer.
> `._.-(,_..'--(,_..'`-.;.'
> > >
> >
>