added Framebuffer tracking to debug GL interface

This delivery is the next version of the debug GL interface.
This version adds:

 tracking of Framebuffer objects
 some refactoring to move flag setting/resetting and ref/unref into the GrDebugGL set* calls
 some minor changes to other classes to get a clean exit (probably not real leaks)
 the addition of a --debuggl switch to gm

[bsalomon, 2012-03-21 13:13:42]

LGTM. Minor style nit: Opening braces don't get their own line in skia.

http://codereview.appspot.com/5866043/diff/1/src/gpu/gl/GrGpuGLShaders.cpp
File src/gpu/gl/GrGpuGLShaders.cpp (right):

http://codereview.appspot.com/5866043/diff/1/src/gpu/gl/GrGpuGLShaders.cpp#ne...
src/gpu/gl/GrGpuGLShaders.cpp:334: GL_CALL(UseProgram(0));
Nice catch.

Inside of chrome there are cases where our destructor can get called after the
GL context has gone away. We *should* set fHWProgramID to 0 when we're notified
that ctx is gone (though it appears that we do not). So let's check that here
before we make the GL call. It would prevent us from making a GL call into a
dead context. And in abandonResources() in this file we should set it to zero.
This gets called when we get notified of a lost context.

http://codereview.appspot.com/5866043/diff/1/src/gpu/gl/SkGLContext.cpp
File src/gpu/gl/SkGLContext.cpp (right):

http://codereview.appspot.com/5866043/diff/1/src/gpu/gl/SkGLContext.cpp#newco...
src/gpu/gl/SkGLContext.cpp:18: SK_GL(*this, DeleteFramebuffers(1, &fFBO));
yay, it works!

[robertphillips, 2012-03-21 17:30:48]

This patch should address the bracket issue and the potential UseProgram in a
dead context.

Note that I undid my fix for the Linux compiler complaints until I have resolved
that issue.

[robertphillips, 2012-03-21 17:30:55]

http://codereview.appspot.com/5866043/diff/1/src/gpu/gl/GrGpuGLShaders.cpp
File src/gpu/gl/GrGpuGLShaders.cpp (right):

http://codereview.appspot.com/5866043/diff/1/src/gpu/gl/GrGpuGLShaders.cpp#ne...
src/gpu/gl/GrGpuGLShaders.cpp:334: GL_CALL(UseProgram(0));
On 2012/03/21 13:13:42, bsalomon wrote:
> Nice catch.
> 
> Inside of chrome there are cases where our destructor can get called after the
> GL context has gone away. We *should* set fHWProgramID to 0 when we're
notified
> that ctx is gone (though it appears that we do not). So let's check that here
> before we make the GL call. It would prevent us from making a GL call into a
> dead context. And in abandonResources() in this file we should set it to zero.
> This gets called when we get notified of a lost context.
> 

Done.

[bsalomon, 2012-03-21 17:34:41]

On 2012/03/21 17:30:55, robertphillips wrote:
> http://codereview.appspot.com/5866043/diff/1/src/gpu/gl/GrGpuGLShaders.cpp
> File src/gpu/gl/GrGpuGLShaders.cpp (right):
> 
>
http://codereview.appspot.com/5866043/diff/1/src/gpu/gl/GrGpuGLShaders.cpp#ne...
> src/gpu/gl/GrGpuGLShaders.cpp:334: GL_CALL(UseProgram(0));
> On 2012/03/21 13:13:42, bsalomon wrote:
> > Nice catch.
> > 
> > Inside of chrome there are cases where our destructor can get called after
the
> > GL context has gone away. We *should* set fHWProgramID to 0 when we're
> notified
> > that ctx is gone (though it appears that we do not). So let's check that
here
> > before we make the GL call. It would prevent us from making a GL call into a
> > dead context. And in abandonResources() in this file we should set it to
zero.
> > This gets called when we get notified of a lost context.
> > 
> 
> Done.

LGTM

[robertphillips, 2012-03-21 18:51:15]

committed as r3455