[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Lifetime of WebGL objects in Firefox and Webkit
Chiming in late so apologies if I missed a beat: is there a real design issue here or not? It seems like a) there are bugs in some browsers (likely) and b) there is a lot of sloppy JS code out there and the developers are going to have to be even more careful than when building 2D apps (more likely). But beyond these two are there actually features the browsers should be adding, and thus the spec? I am skeptical. Good JS practice is the best bet, not creating closures, not hanging on to pointers out of sloppiness, etc. Or am I missing something?
On Wed, Jun 29, 2011 at 12:54 PM, Glenn Maynard <email@example.com>
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?
Implementations are free to do this if they want, but it's a separate issue. I don't know if other JS APIs do this sort of thing under memory pressure.
By the way, remember that GPUs aren't limited to GPU memory: when low on memory, textures are swapped out to main memory (speaking roughly), and you can allocate far more texture memory than you have GPU space. This means that if you're hitting GL_OOM, you're probably running out of main memory, not just GPU memory.
On Wed, Jun 29, 2011 at 12:15 PM, Gregg Tavares (wrk) <firstname.lastname@example.org>
> 2) Freeing the texture managed by WebGLTexture object.
The underlying GPU texture should always be deleted when the WebGLTexture object is collected, if it wasn't already deleted by the user. I'd be surprised if there's disagreement about that much.
Tony Parisi email@example.com
CTO at Large 415.902.8002
Follow me on Twitter! http://twitter.com/auradeluxe
Read my blog at http://www.tonyparisi.com/