[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Lifetime of WebGL objects in Firefox and Webkit



On Tue, Jun 28, 2011 at 6:30 PM, Gregg Tavares (wrk) <gman@google.com> wrote:
It's hard to imagine a WebGL app that would run all that long if it did anything like this. A 512meg card would fill up on a image viewer after 500 images or less. ÂA video player would run out of memory in probably 5-15 seconds.

The issue isn't merely running out of memory entirely; it's memory waste. Firefox regularly takes 1.7 GB of memory for me; it doesn't crash, but it's still using a lot of memory that I'd sooner be using elsewhere.

It's pretty easy to see WebGL apps that would run for a very long time, progressively leaking memory. For example, applications like Google Maps load tiles as needed. It can take a fair amount of usage to load enough tiles to take a lot of memory, so if these aren't reclaimed it'll work for most people, especially if most users use the application briefly and close it--but it'll waste memory, break on systems with low memory, and break eventually for people who keep tabs open for a long time.

(This isn't theoretical. WebKit has a long-standing bug where dynamic images progressively leak memory, which is triggered by GMaps in Chrome--last I checked--and mobile WebKits. Just to be clear, that isn't a WebGL problem, just an analogous one.)

The basic problem with *requiring* deallocation is that it imports all of the classic problems of explicit memory management into _javascript_, requiring very careful transfer of ownership, exception handling/error code paths, and so on, as you have to do in C and C++. It's not the normal case that's hard; in complex applications it's these less common cases where you're likely to see subtle, progressive leaks.

In short, the point is: it's fine to call this "sloppy WebGL code"--people clearly should try to get this right--but it's still ultimately a bug in the WebGL implementation. An object should not hold a strong reference to another unless it's specified as doing so, and applications should be able to depend on this, as they can with the rest of the Web platform.

--
Glenn Maynard