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

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





----- Original Message -----
> On Tue, Jun 28, 2011 at 10:31 PM, Gary Coding <garycoding@gmail.com>
> wrote:
> > Gregg,
> > How about your idea that after every call to glGenXXX, glCreateXXX,
> > glBufferData, glTexImage2D, glCopyImage2D, and glRenderbufferStorage
> > the
> > browser would check for GL_OUT_OF_MEMORY, then if so do a GC and
> > then try
> > the call again?
> > It may be more than the spec requires, but it does address the issue
> > of the
> > sloppy code that's leaked too much to keep going.
> > Are there any draw backs to this behavior that I don't see?
> 
> Yes, potentially stalling the pipeline and killing performance. Why
> are we trying to fix/optimize "sloppy code"? There's all sorts of
> things WebGL (and OpenGL and JavaScript and everything else) authors
> can do that will result in various non-ideal things happening -- why
> focus on this one? WebGL is still OpenGL; just because it's on the
> web doesn't mean that WebGL authors can ignore memory management. (I
> don't buy the argument that there's no memory management in JS --
> there wasn't any 3D in JS either at one point, and there's nothing to
> say that there won't be some kind of explicit resource management in
> JS in the future.)
> 
> It would take a lot of effort for a browser to even get to a point
> where this kind of sort of worked in some cases, without ever being
> able to catch all the cases where a GC could prevent out of memory or
> similar. Why spend that effort for a halfway solution? For Firefox
> at least, I'd much rather see antialiasing support, out of process GL
> rendering, dx/gl interop, or a number of other things before even
> thinking about trying to help developers who are writing bad/leaky
> code leak less.

https://bugzilla.mozilla.org/show_bug.cgi?id=656120
just landed, which means that GC pauses are guaranteed to happen on a regular basis (I believe the current period is 20 seconds), except when completely idle. With this change, the notion that GC occurs at completely undefined time if at all, is no longer true in Firefox. This means that the presently discussed kind of "bad" JS code would not just "leak less", it would leak for at most 20 seconds. There's this trend to release memory much more aggressively than we have been so far, this particular bug is reducing Firefox's memory usage by 10% on ROME, and I believe that the change I'm proposing here would fit nicely with that.

We have several bugs filed against WebGL consuming too much memory to be usable on certain sites:
https://bugzilla.mozilla.org/show_bug.cgi?id=657115 (on ROME)
https://bugzilla.mozilla.org/show_bug.cgi?id=643651
So while I have no idea whether the present proposal is what these sites need (bug 655363 will help understand that), WebGL memory usage on real world sites matters a lot to me.

Benoit
-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------