RESOLVED FIXED80895
After webgl canvas resize, bindings might be lost
https://bugs.webkit.org/show_bug.cgi?id=80895
Summary After webgl canvas resize, bindings might be lost
Zhenyao Mo
Reported 2012-03-12 14:53:23 PDT
This includes texture/framebuffer/renderbuffer bindings.
Attachments
Patch (4.97 KB, patch)
2012-03-12 16:09 PDT, Zhenyao Mo
senorblanco: review+
Zhenyao Mo
Comment 1 2012-03-12 16:09:40 PDT
Zhenyao Mo
Comment 2 2012-03-12 16:10:31 PDT
Stephen, Ken is probably out, can you review this patch?
Stephen White
Comment 3 2012-03-12 18:39:18 PDT
This looks ok, although I'm not super-familiar with this code. r=me, in case this needs to go in in a hurry. If it's DrawingBuffer that's messing up the bindings, should it be DrawingBuffer that restores them? Or does this save us doing a bunch of get()'s?
Stephen White
Comment 4 2012-03-12 18:39:44 PDT
Comment on attachment 131436 [details] Patch
Zhenyao Mo
Comment 5 2012-03-12 18:43:10 PDT
(In reply to comment #3) > This looks ok, although I'm not super-familiar with this code. r=me, in case this needs to go in in a hurry. > > If it's DrawingBuffer that's messing up the bindings, should it be DrawingBuffer that restores them? Or does this save us doing a bunch of get()'s? If DrawingBuffer needs to restore the binding states, it needs to track the current bindings, which is not trivia. For example, if a current bound framebuffer is deleted, we need to reset the binding, etc. This is basically duplicate all the logic in WebGLRenderingContext in DrawingBuffer and GraphicsContext3D. That's why I restore the bindings in WebGLRenderingContext.
Stephen White
Comment 6 2012-03-12 18:51:36 PDT
(In reply to comment #5) > (In reply to comment #3) > > This looks ok, although I'm not super-familiar with this code. r=me, in case this needs to go in in a hurry. > > > > If it's DrawingBuffer that's messing up the bindings, should it be DrawingBuffer that restores them? Or does this save us doing a bunch of get()'s? > > If DrawingBuffer needs to restore the binding states, it needs to track the current bindings, which is not trivia. For example, if a current bound framebuffer is deleted, we need to reset the binding, etc. This is basically duplicate all the logic in WebGLRenderingContext in DrawingBuffer and GraphicsContext3D. That's why I restore the bindings in WebGLRenderingContext. Sounds reasonable. I forgot to mention: that test is great. Is that something that's worth upstreaming to the WebGL conformance suite?
Zhenyao Mo
Comment 7 2012-03-12 18:53:54 PDT
Jeff Timanus
Comment 8 2012-03-13 08:32:33 PDT
This change looks good. DrawingBuffer::reset plays with the bound textures and framebuffers, which need to be re-assigned after the resize.
Zhenyao Mo
Comment 9 2012-03-13 09:15:22 PDT
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #3) > > > This looks ok, although I'm not super-familiar with this code. r=me, in case this needs to go in in a hurry. > > > > > > If it's DrawingBuffer that's messing up the bindings, should it be DrawingBuffer that restores them? Or does this save us doing a bunch of get()'s? > > > > If DrawingBuffer needs to restore the binding states, it needs to track the current bindings, which is not trivia. For example, if a current bound framebuffer is deleted, we need to reset the binding, etc. This is basically duplicate all the logic in WebGLRenderingContext in DrawingBuffer and GraphicsContext3D. That's why I restore the bindings in WebGLRenderingContext. > > Sounds reasonable. > > I forgot to mention: that test is great. Is that something that's worth upstreaming to the WebGL conformance suite? The test was checked in to khronos by Gregg, and I copied from there, so it's already in the suite.
Note You need to log in before you can comment on or make changes to this bug.