Move most of the transform logic into the primitive processors

Move most of the transform logic into the primitive processors

BUG=skia:

Committed: https://skia.googlesource.com/skia/+/abb52a1a70a81915c6196e0fb3e9bcb05e8be14d

[joshualitt, 2015-01-07 15:55:34]

joshualitt@google.com changed reviewers:
+ bsalomon@google.com

[joshualitt, 2015-01-07 15:58:18]

joshualitt@google.com changed reviewers:
+ joshualitt@google.com

[joshualitt, 2015-01-07 15:58:18]

Brian, the heart of this change is in GrGeometryProcessor.cpp.  I will post a
follow up CL which moves these classes out of GrGeometryProcessor.cpp.

I think this CL is a massive improvement, but there is still some small cleanups
which need to happen.  Mostly the local coords stuff is still a bit exposed,
because of its use in generating a key for the fragment processor, and OptState
still needs separate PrimProc / GeoProc pointers.  I'll try and figure out a way
to clean this up in a follow on CL.

[joshualitt, 2015-01-07 16:52:42]

On 2015/01/07 15:58:18, joshualitt wrote:
> Brian, the heart of this change is in GrGeometryProcessor.cpp.  I will post a
> follow up CL which moves these classes out of GrGeometryProcessor.cpp.
> 
> I think this CL is a massive improvement, but there is still some small
cleanups
> which need to happen.  Mostly the local coords stuff is still a bit exposed,
> because of its use in generating a key for the fragment processor, and
OptState
> still needs separate PrimProc / GeoProc pointers.  I'll try and figure out a
way
> to clean this up in a follow on CL.

Okay, there was only a bit more cleanup I could actually do before we have
deferred, so I just added it to this CL.  We can combine a bit more if we drop
legacy Nvpr, but I think the rest of the cleanup should wait until after
deferred(aside from the file migration, which I will do now)

[bsalomon, 2015-01-13 14:51:14]

https://codereview.chromium.org/822423004/diff/160001/include/gpu/GrFragmentP...
File include/gpu/GrFragmentProcessor.h (right):

https://codereview.chromium.org/822423004/diff/160001/include/gpu/GrFragmentP...
include/gpu/GrFragmentProcessor.h:50: const SkTArray<const GrCoordTransform*,
true>& coordTransforms() const {
Why expose the internal container type and not use the above two functions?

https://codereview.chromium.org/822423004/diff/160001/src/gpu/GrAAConvexPathR...
File src/gpu/GrAAConvexPathRenderer.cpp (right):

https://codereview.chromium.org/822423004/diff/160001/src/gpu/GrAAConvexPathR...
src/gpu/GrAAConvexPathRenderer.cpp:569:
vsBuilder->transformToNormalizedDeviceSpace(pos3);
won't this be repeated for every GP? Maybe we should just tell the caller of
emitcode (or have it tell this function) the name of the var to put the
pre-normalized-skdevicecoord values and have the caller do this.

Also if the caller was the base class (i.e. make this onEmitCode) then it could
insert the repetitive call to this->emitTransforms() and add the attributes.

https://codereview.chromium.org/822423004/diff/160001/src/gpu/GrOvalRenderer.cpp
File src/gpu/GrOvalRenderer.cpp (right):

https://codereview.chromium.org/822423004/diff/160001/src/gpu/GrOvalRenderer....
src/gpu/GrOvalRenderer.cpp:107: const char* pos3 = "pos3";
why do this and not just hardcode pos3 in the below strings? Or we can at least
do static const here.

[joshualitt, 2015-01-13 16:29:31]

Most of the feedback has been incorporated.  I actually can't do the emit
transforms in the base class though, because the default geo proc factory does
local coord shennanigans.

[joshualitt, 2015-01-13 21:19:19]

On 2015/01/13 16:29:31, joshualitt wrote:
> Most of the feedback has been incorporated.  I actually can't do the emit
> transforms in the base class though, because the default geo proc factory does
> local coord shennanigans.

Any other feedback on this CL?

[bsalomon, 2015-01-13 21:55:15]

lgtm

https://codereview.chromium.org/822423004/diff/180001/src/gpu/gl/GrGLGeometry...
File src/gpu/gl/GrGLGeometryProcessor.h (right):

https://codereview.chromium.org/822423004/diff/180001/src/gpu/gl/GrGLGeometry...
src/gpu/gl/GrGLGeometryProcessor.h:139: virtual void onEmitCode(EmitArgs&) = 0;
Shoulnd't onEmitCode be private?

[joshualitt, 2015-01-13 22:51:01]

The CQ bit was checked by joshualitt@google.com

[commit-bot: I haz the power, 2015-01-13 22:51:24]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/822423004/220001

[commit-bot: I haz the power, 2015-01-13 23:02:14]

Committed patchset #12 (id:220001) as
https://skia.googlesource.com/skia/+/abb52a1a70a81915c6196e0fb3e9bcb05e8be14d