Make GrStencilState a class to enable future optimizations

[bsalomon, 2011-12-15 17:01:34]

It's OK to cry.

[TomH, 2011-12-15 19:18:07]

LGTM otherwise.

http://codereview.appspot.com/5492047/diff/1007/src/gpu/GrDefaultPathRenderer...
File src/gpu/GrDefaultPathRenderer.cpp (right):

http://codereview.appspot.com/5492047/diff/1007/src/gpu/GrDefaultPathRenderer...
src/gpu/GrDefaultPathRenderer.cpp:44:
GR_STATIC_CONST_SAME_STENCIL_SETTINGS(gEOStencilPass,
Eww.

http://codereview.appspot.com/5492047/diff/1007/src/gpu/GrStencil.cpp
File src/gpu/GrStencil.cpp (right):

http://codereview.appspot.com/5492047/diff/1007/src/gpu/GrStencil.cpp#newcode11
src/gpu/GrStencil.cpp:11: 
Disabled disappeared?

http://codereview.appspot.com/5492047/diff/1007/src/gpu/GrStencil.h
File src/gpu/GrStencil.h (right):

http://codereview.appspot.com/5492047/diff/1007/src/gpu/GrStencil.h#newcode240
src/gpu/GrStencil.h:240: 
Can we have a comment to describe why we have this abomination?

[bsalomon, 2011-12-15 20:33:52]

Closed with r2882

http://codereview.appspot.com/5492047/diff/1007/src/gpu/GrDefaultPathRenderer...
File src/gpu/GrDefaultPathRenderer.cpp (right):

http://codereview.appspot.com/5492047/diff/1007/src/gpu/GrDefaultPathRenderer...
src/gpu/GrDefaultPathRenderer.cpp:44:
GR_STATIC_CONST_SAME_STENCIL_SETTINGS(gEOStencilPass,
On 2011/12/15 19:18:07, TomH wrote:
> Eww.

Yeah, I got rid of _SETTINGS in the final version. It's still ugly.

http://codereview.appspot.com/5492047/diff/1007/src/gpu/GrStencil.cpp
File src/gpu/GrStencil.cpp (right):

http://codereview.appspot.com/5492047/diff/1007/src/gpu/GrStencil.cpp#newcode11
src/gpu/GrStencil.cpp:11: 
On 2011/12/15 19:18:07, TomH wrote:
> Disabled disappeared?

It was used in one comparison inside an assert. We already have .isDisabled() on
the class.

http://codereview.appspot.com/5492047/diff/1007/src/gpu/GrStencil.h
File src/gpu/GrStencil.h (right):

http://codereview.appspot.com/5492047/diff/1007/src/gpu/GrStencil.h#newcode240
src/gpu/GrStencil.h:240: 
On 2011/12/15 19:18:07, TomH wrote:
> Can we have a comment to describe why we have this abomination?

I added this above the struct definition:
/**
 * GrStencilState needs to be a class with accessors and setters so that it
 * can maintain flags related to its current state. However, we also want to
 * be able to declare pre-made stencil settings at compile time (without
 * inserting static initializer code). So all the data members are in this
 * struct. A macro defined after the class can be used to jam an instance of
 * this struct that is created from an initializer list into a
 * GrStencilSettings. (We hang our heads in shame.)
 */

[TomH, 2011-12-15 20:36:37]

On 2011/12/15 20:33:52, bsalomon wrote:
> http://codereview.appspot.com/5492047/diff/1007/src/gpu/GrStencil.h#newcode240
> src/gpu/GrStencil.h:240: 
> On 2011/12/15 19:18:07, TomH wrote:
> > Can we have a comment to describe why we have this abomination?
> 
> I added this above the struct definition:
> /**
>  * GrStencilState needs to be a class with accessors and setters so that it
>  * can maintain flags related to its current state. However, we also want to
>  * be able to declare pre-made stencil settings at compile time (without
>  * inserting static initializer code). So all the data members are in this
>  * struct. A macro defined after the class can be used to jam an instance of
>  * this struct that is created from an initializer list into a
>  * GrStencilSettings. (We hang our heads in shame.)
>  */

Well said.