Move SW path renderer back to TU/sampler #2

So ... now that I have actually encountered a test case that requires the SW path renderer, I need to move the SW path renderer back to TU #2. The problem is that the SW path renderer uses UV's (on a rect) to render the SW-created path back to the gpu. For the gpu AA clip mask we don't use uvs and obviously we can't use both. We could investigate switching the SW path renderer over to using generated uvs (like the AA clip mask) but, for now, I would like to leave it alone.

This reverts r3813 (http://codereview.appspot.com/6138057/)

[TomH, 2012-05-02 18:58:13]

Didn't I say something on the original patch that I wasn't qualified to review
it? Now we have evidence!

LGTM

Nit: would be nice to refer to the code review that this is reverting.

[robertphillips, 2012-05-02 19:28:24]

Added reversion comment to code review (and commit)

Committed as r3827

[bsalomon, 2012-05-07 12:51:39]

http://codereview.appspot.com/6159046/diff/1/src/gpu/GrSoftwarePathRenderer.cpp
File src/gpu/GrSoftwarePathRenderer.cpp (right):

http://codereview.appspot.com/6159046/diff/1/src/gpu/GrSoftwarePathRenderer.c...
src/gpu/GrSoftwarePathRenderer.cpp:233: kPathMaskStage = GrPaint::kTotalStages,
Annoying post-review: It might be a good idea to add
GrAssert(!target->drawState()->getTextures(kPathMaskStage)). 

We could also document in the GrPathRenderer base class that stages kTotalStages
and later are available for use by the path renderer (or even provide an enum in
the base class, kFirstAvailableStage)

[TomH, 2012-05-07 12:56:41]

Annoying post-review! For great code quality! All your technical debt are belong
to us!

[robertphillips, 2012-05-07 17:41:47]

http://codereview.appspot.com/6159046/diff/1/src/gpu/GrSoftwarePathRenderer.cpp
File src/gpu/GrSoftwarePathRenderer.cpp (right):

http://codereview.appspot.com/6159046/diff/1/src/gpu/GrSoftwarePathRenderer.c...
src/gpu/GrSoftwarePathRenderer.cpp:233: kPathMaskStage = GrPaint::kTotalStages,
I have added the assert (to be delivered later).

On the second half, where would it be appropriate to centrally document Ganesh'
stage usage? Right now it takes some scrabbling through the code to figure out
that both glyphs and the SW path renderer use stage 2 and that stage 1 is
reserved for mask rendering.

[bsalomon, 2012-05-07 18:10:52]

http://codereview.appspot.com/6159046/diff/1/src/gpu/GrSoftwarePathRenderer.cpp
File src/gpu/GrSoftwarePathRenderer.cpp (right):

http://codereview.appspot.com/6159046/diff/1/src/gpu/GrSoftwarePathRenderer.c...
src/gpu/GrSoftwarePathRenderer.cpp:233: kPathMaskStage = GrPaint::kTotalStages,
On 2012/05/07 17:41:47, robertphillips wrote:
> I have added the assert (to be delivered later).
> 
> On the second half, where would it be appropriate to centrally document
Ganesh'
> stage usage? Right now it takes some scrabbling through the code to figure out
> that both glyphs and the SW path renderer use stage 2 and that stage 1 is
> reserved for mask rendering.

Perhaps in GrDrawState.h we can say that the first GrPaint::kTotalStages are
reserved for using by GrContext when setting up the draw. GrPathRenderer and
GrTextContext base classes can document that the remaining stages are available
for subclass usage. We shouldn't go overboard documenting this since as the
shader generator refactoring proceeds we will shed the current model of an array
stages with color/coverage separation specified by an index.