Gradient CustomStage integration

This works.

[TomH, 2012-06-01 20:27:49]

Muahaha. They laughed at me when I said I had a CL that removed 40 LOC. Who's
laughing now?

http://codereview.appspot.com/6245078/diff/8001/include/gpu/GrSamplerState.h
File include/gpu/GrSamplerState.h (left):

http://codereview.appspot.com/6245078/diff/8001/include/gpu/GrSamplerState.h#...
include/gpu/GrSamplerState.h:41: /**
We might want to make sure we've got these semantics documented somewhere else?

http://codereview.appspot.com/6245078/diff/8001/include/gpu/GrSamplerState.h#...
include/gpu/GrSamplerState.h:146: bool isGradient() const {
Didn't have any callers!

http://codereview.appspot.com/6245078/diff/8001/include/gpu/GrSamplerState.h
File include/gpu/GrSamplerState.h (right):

http://codereview.appspot.com/6245078/diff/8001/include/gpu/GrSamplerState.h#...
include/gpu/GrSamplerState.h:177: bool                fSwapRAndB;
Reorder to see if we can trim a few pad bytes.

http://codereview.appspot.com/6245078/diff/8001/src/gpu/SkGpuDevice.cpp
File src/gpu/SkGpuDevice.cpp (right):

http://codereview.appspot.com/6245078/diff/8001/src/gpu/SkGpuDevice.cpp#newco...
src/gpu/SkGpuDevice.cpp:518: tileModes, twoPointParams);
Next step (to make Mike happy): write shader::getCustomStage() and not have to
bother with asABitmap() (? assuming we don't have to worry too much about the
params being passed in invalidating the assumptions of our custom stage
implementations - but then we should probably just be improving those).

http://codereview.appspot.com/6245078/diff/8001/src/gpu/effects/GrGradientEff...
File src/gpu/effects/GrGradientEffects.cpp (right):

http://codereview.appspot.com/6245078/diff/8001/src/gpu/effects/GrGradientEff...
src/gpu/effects/GrGradientEffects.cpp:215: if (!fIsDegenerate) {
Oops.

http://codereview.appspot.com/6245078/diff/8001/src/gpu/gl/GrGpuGL.h
File src/gpu/gl/GrGpuGL.h (left):

http://codereview.appspot.com/6245078/diff/8001/src/gpu/gl/GrGpuGL.h#oldcode184
src/gpu/gl/GrGpuGL.h:184: GrSamplerState::SampleMode mode,
Luckily, parameter wasn't being used

[bsalomon, 2012-06-01 20:37:27]

I love this change! LGTM (but let's save the documentation of the parameters
that specify the gradients)

http://codereview.appspot.com/6245078/diff/8001/include/gpu/GrSamplerState.h
File include/gpu/GrSamplerState.h (left):

http://codereview.appspot.com/6245078/diff/8001/include/gpu/GrSamplerState.h#...
include/gpu/GrSamplerState.h:41: /**
On 2012/06/01 20:27:50, TomH wrote:
> We might want to make sure we've got these semantics documented somewhere
else?

Yes, should we port this documentation GrGradientEffects.h?

http://codereview.appspot.com/6245078/diff/8001/src/gpu/SkGpuDevice.cpp
File src/gpu/SkGpuDevice.cpp (right):

http://codereview.appspot.com/6245078/diff/8001/src/gpu/SkGpuDevice.cpp#newco...
src/gpu/SkGpuDevice.cpp:16: #include "SkGpuDevice.h"
Let's move this include to the top (since it is the decl of the class being
defined here)

http://codereview.appspot.com/6245078/diff/8001/src/gpu/SkGpuDevice.cpp#newco...
src/gpu/SkGpuDevice.cpp:518: tileModes, twoPointParams);
On 2012/06/01 20:27:50, TomH wrote:
> Next step (to make Mike happy): write shader::getCustomStage() and not have to
> bother with asABitmap() (? assuming we don't have to worry too much about the
> params being passed in invalidating the assumptions of our custom stage
> implementations - but then we should probably just be improving those).

I think this is "a" next step but IMO isn't "the" next step. I think we should
keep generalizing what stages can do (and not do).

http://codereview.appspot.com/6245078/diff/8001/src/gpu/effects/GrGradientEff...
File src/gpu/effects/GrGradientEffects.cpp (right):

http://codereview.appspot.com/6245078/diff/8001/src/gpu/effects/GrGradientEff...
src/gpu/effects/GrGradientEffects.cpp:215: if (!fIsDegenerate) {
On 2012/06/01 20:27:50, TomH wrote:
> Oops.

heh

http://codereview.appspot.com/6245078/diff/8001/src/gpu/gl/GrGLProgram.cpp
File src/gpu/gl/GrGLProgram.cpp (left):

http://codereview.appspot.com/6245078/diff/8001/src/gpu/gl/GrGLProgram.cpp#ol...
src/gpu/gl/GrGLProgram.cpp:1360: }
hell yeah

http://codereview.appspot.com/6245078/diff/8001/src/gpu/gl/GrGLProgram.h
File src/gpu/gl/GrGLProgram.h (left):

http://codereview.appspot.com/6245078/diff/8001/src/gpu/gl/GrGLProgram.h#oldc...
src/gpu/gl/GrGLProgram.h:173: kCoordMappingCnt
weeeeeeeeeeeeeeeeeeeeeeee

[TomH, 2012-06-01 20:44:12]

On 2012/06/01 20:37:27, bsalomon wrote:
> On 2012/06/01 20:27:50, TomH wrote:
> > We might want to make sure we've got these semantics documented somewhere
> else?
> Yes, should we port this documentation GrGradientEffects.h?
Done.

> src/gpu/SkGpuDevice.cpp:16: #include "SkGpuDevice.h"
> Let's move this include to the top (since it is the decl of the class being
> defined here)
Done.

> On 2012/06/01 20:27:50, TomH wrote:
> > Next step (to make Mike happy): write shader::getCustomStage() and not have
to
> > bother with asABitmap() (? assuming we don't have to worry too much about
the
> > params being passed in invalidating the assumptions of our custom stage
> > implementations - but then we should probably just be improving those).
> 
> I think this is "a" next step but IMO isn't "the" next step. I think we should
> keep generalizing what stages can do (and not do).
Yes, "a" next step in the grand scheme of things. Get around to it when we want
to bother with keeping Mike happy.

Committed (in a fit of folly late on a Friday) as r4129.