[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 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.

     - Vlad
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