GrFP can express distance vector field req., program builder declares variable for it

GrFP can express distance vector field req.,  program builder declares variable for it

This update allows fragment processors to require a field of vectors to the nearest edge. This requirement propagates:

- from child FPs to their parent
- from parent FPs to the GrPaint
- from GrPaint through the PipelineBuilder into GrPipeline
- acessed from GrPipeline by GrGLSLProgramBuilder

GrGLSL generates a variable for the distance vector and passes it down to the GeometryProcessor->emitCode() method.

This CL's base is the CL for adding the BevelNormalSource API: https://codereview.chromium.org/2080993002

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2114993002

Committed: https://skia.googlesource.com/skia/+/4ef6dfa7089c092c67b0d5ec34e89c1e319af196
Committed: https://skia.googlesource.com/skia/+/9b03e7b29d963ea333a66dc5353e94f6391eb899

[dvonbeck, 2016-07-01 17:55:19]

Description was changed from

==========
GrFP can express distance vector field req.,  program builder declares variable
for it

This update allows fragment processors to require a field of vectors to the
nearest edge. This requirement propagates:

- from child FPs to their parent
- from parent FPs to the GrPaint
- from GrPaint through the PipelineBuilder into GrPipeline
- acessed from GrPipeline by GrGLSLProgramBuilder

GrGLSL generates a variable for the distance vector and passes it down to the
GeometryProcessor->emitCode() method.

BUG=skia:
==========

to

==========
GrFP can express distance vector field req.,  program builder declares variable
for it

This update allows fragment processors to require a field of vectors to the
nearest edge. This requirement propagates:

- from child FPs to their parent
- from parent FPs to the GrPaint
- from GrPaint through the PipelineBuilder into GrPipeline
- acessed from GrPipeline by GrGLSLProgramBuilder

GrGLSL generates a variable for the distance vector and passes it down to the
GeometryProcessor->emitCode() method.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2114993002
==========

[dvonbeck, 2016-07-01 18:51:20]

dvonbeck@google.com changed reviewers:
+ egdaniel@google.com, robertphillips@google.com

[robertphillips, 2016-07-11 17:55:41]

https://codereview.chromium.org/2114993002/diff/80001/src/gpu/glsl/GrGLSLFrag...
File src/gpu/glsl/GrGLSLFragmentShaderBuilder.h (right):

https://codereview.chromium.org/2114993002/diff/80001/src/gpu/glsl/GrGLSLFrag...
src/gpu/glsl/GrGLSLFragmentShaderBuilder.h:173: const char* fragmentPosition()
override;
same order as above ?

https://codereview.chromium.org/2114993002/diff/80001/src/gpu/glsl/GrGLSLProg...
File src/gpu/glsl/GrGLSLProgramBuilder.cpp (right):

https://codereview.chromium.org/2114993002/diff/80001/src/gpu/glsl/GrGLSLProg...
src/gpu/glsl/GrGLSLProgramBuilder.cpp:94: 
Maybe emit a comment:

// Un-normalized vector to the closed geometric edge (in source space)

?

[egdaniel, 2016-07-12 13:46:42]

I think we should also add the code were we pass the string into the GP's
EmitArgs struct if it is required. Thus all the connecting code with fully be
there and we can start working on updating either GPs or NormalSources.

https://codereview.chromium.org/2114993002/diff/80001/include/gpu/GrPaint.h
File include/gpu/GrPaint.h (right):

https://codereview.chromium.org/2114993002/diff/80001/include/gpu/GrPaint.h#n...
include/gpu/GrPaint.h:150: fUsesDistanceVectorField =
paint.fUsesDistanceVectorField;
would this not be taken care of by the processor equality check?

https://codereview.chromium.org/2114993002/diff/80001/src/gpu/gl/GrGLProgramD...
File src/gpu/gl/GrGLProgramDesc.cpp (right):

https://codereview.chromium.org/2114993002/diff/80001/src/gpu/gl/GrGLProgramD...
src/gpu/gl/GrGLProgramDesc.cpp:185: if (pipeline.usesDistanceVectorField()) {
I know I said we should add this to the key here, but now that I think about
this more, I feel like the use of it would already be captured by the class id
key of the processor who reads it.

https://codereview.chromium.org/2114993002/diff/80001/src/gpu/glsl/GrGLSLFrag...
File src/gpu/glsl/GrGLSLFragmentShaderBuilder.h (right):

https://codereview.chromium.org/2114993002/diff/80001/src/gpu/glsl/GrGLSLFrag...
src/gpu/glsl/GrGLSLFragmentShaderBuilder.h:58: virtual const char*
distanceVectorName() const = 0;
with other changes mentioned in comments, I think we should only need
distanceVectorName

https://codereview.chromium.org/2114993002/diff/80001/src/gpu/glsl/GrGLSLProg...
File src/gpu/glsl/GrGLSLProgramBuilder.cpp (right):

https://codereview.chromium.org/2114993002/diff/80001/src/gpu/glsl/GrGLSLProg...
src/gpu/glsl/GrGLSLProgramBuilder.cpp:92:
this->nameVariable(&outputDistanceVectorStr, '\0', "outputDistanceVector");
I think I would prefer hard coding the name we want to use into
GLSLFragmentShaderBuilder instead of us telling the fragment shader what the
name should be.

[dvonbeck, 2016-07-13 15:17:13]

https://codereview.chromium.org/2114993002/diff/80001/include/gpu/GrPaint.h
File include/gpu/GrPaint.h (right):

https://codereview.chromium.org/2114993002/diff/80001/include/gpu/GrPaint.h#n...
include/gpu/GrPaint.h:150: fUsesDistanceVectorField =
paint.fUsesDistanceVectorField;
On 2016/07/12 13:46:42, egdaniel wrote:
> would this not be taken care of by the processor equality check?

This is the assignment operator. The flag is only set at add*FragmentProcessor()
calls, which wouldn't happen in an assignment.

https://codereview.chromium.org/2114993002/diff/80001/src/gpu/gl/GrGLProgramD...
File src/gpu/gl/GrGLProgramDesc.cpp (right):

https://codereview.chromium.org/2114993002/diff/80001/src/gpu/gl/GrGLProgramD...
src/gpu/gl/GrGLProgramDesc.cpp:185: if (pipeline.usesDistanceVectorField()) {
On 2016/07/12 13:46:42, egdaniel wrote:
> I know I said we should add this to the key here, but now that I think about
> this more, I feel like the use of it would already be captured by the class id
> key of the processor who reads it.

The GeoProc?

https://codereview.chromium.org/2114993002/diff/80001/src/gpu/glsl/GrGLSLFrag...
File src/gpu/glsl/GrGLSLFragmentShaderBuilder.h (right):

https://codereview.chromium.org/2114993002/diff/80001/src/gpu/glsl/GrGLSLFrag...
src/gpu/glsl/GrGLSLFragmentShaderBuilder.h:58: virtual const char*
distanceVectorName() const = 0;
On 2016/07/12 13:46:42, egdaniel wrote:
> with other changes mentioned in comments, I think we should only need
> distanceVectorName

Done.

https://codereview.chromium.org/2114993002/diff/80001/src/gpu/glsl/GrGLSLFrag...
src/gpu/glsl/GrGLSLFragmentShaderBuilder.h:173: const char* fragmentPosition()
override;
On 2016/07/11 17:55:40, robertphillips wrote:
> same order as above ?

Done.

https://codereview.chromium.org/2114993002/diff/80001/src/gpu/glsl/GrGLSLProg...
File src/gpu/glsl/GrGLSLProgramBuilder.cpp (right):

https://codereview.chromium.org/2114993002/diff/80001/src/gpu/glsl/GrGLSLProg...
src/gpu/glsl/GrGLSLProgramBuilder.cpp:92:
this->nameVariable(&outputDistanceVectorStr, '\0', "outputDistanceVector");
On 2016/07/12 13:46:42, egdaniel wrote:
> I think I would prefer hard coding the name we want to use into
> GLSLFragmentShaderBuilder instead of us telling the fragment shader what the
> name should be.

The thing is, the Geometry Processors get their variable names mangled. That's
why I'm running it through the nameVariable method.

https://codereview.chromium.org/2114993002/diff/80001/src/gpu/glsl/GrGLSLProg...
src/gpu/glsl/GrGLSLProgramBuilder.cpp:94: 
On 2016/07/11 17:55:40, robertphillips wrote:
> Maybe emit a comment:
> 
> // Un-normalized vector to the closed geometric edge (in source space)
> 
> ?

Done.

[egdaniel, 2016-07-13 15:47:02]

https://codereview.chromium.org/2114993002/diff/80001/src/gpu/glsl/GrGLSLProg...
File src/gpu/glsl/GrGLSLProgramBuilder.cpp (right):

https://codereview.chromium.org/2114993002/diff/80001/src/gpu/glsl/GrGLSLProg...
src/gpu/glsl/GrGLSLProgramBuilder.cpp:92:
this->nameVariable(&outputDistanceVectorStr, '\0', "outputDistanceVector");
On 2016/07/13 15:17:13, dvonbeck wrote:
> On 2016/07/12 13:46:42, egdaniel wrote:
> > I think I would prefer hard coding the name we want to use into
> > GLSLFragmentShaderBuilder instead of us telling the fragment shader what the
> > name should be.
> 
> The thing is, the Geometry Processors get their variable names mangled. That's
> why I'm running it through the nameVariable method.

I don't think there is any need for mangling the variable here. We do a similar
thing when we need to declare the the outColor variable. See 
DeclaredColorOutputName()

[dvonbeck, 2016-07-13 16:57:49]

https://codereview.chromium.org/2114993002/diff/80001/src/gpu/glsl/GrGLSLProg...
File src/gpu/glsl/GrGLSLProgramBuilder.cpp (right):

https://codereview.chromium.org/2114993002/diff/80001/src/gpu/glsl/GrGLSLProg...
src/gpu/glsl/GrGLSLProgramBuilder.cpp:92:
this->nameVariable(&outputDistanceVectorStr, '\0', "outputDistanceVector");
On 2016/07/13 15:47:02, egdaniel wrote:
> On 2016/07/13 15:17:13, dvonbeck wrote:
> > On 2016/07/12 13:46:42, egdaniel wrote:
> > > I think I would prefer hard coding the name we want to use into
> > > GLSLFragmentShaderBuilder instead of us telling the fragment shader what
the
> > > name should be.
> > 
> > The thing is, the Geometry Processors get their variable names mangled.
That's
> > why I'm running it through the nameVariable method.
> 
> I don't think there is any need for mangling the variable here. We do a
similar
> thing when we need to declare the the outColor variable. See 
> DeclaredColorOutputName()

Done.

[dvonbeck, 2016-07-13 19:07:15]

Removed DVF boolean from key. Added a boolean to Primitive Processor that
exposes if they have implemented DVF. Used boolean to guard emitted GLSL code,
emits code requiring DVF only if DVF is implemented by GeoProc.

https://codereview.chromium.org/2114993002/diff/80001/src/gpu/gl/GrGLProgramD...
File src/gpu/gl/GrGLProgramDesc.cpp (right):

https://codereview.chromium.org/2114993002/diff/80001/src/gpu/gl/GrGLProgramD...
src/gpu/gl/GrGLProgramDesc.cpp:185: if (pipeline.usesDistanceVectorField()) {
On 2016/07/13 15:17:13, dvonbeck wrote:
> On 2016/07/12 13:46:42, egdaniel wrote:
> > I know I said we should add this to the key here, but now that I think about
> > this more, I feel like the use of it would already be captured by the class
id
> > key of the processor who reads it.
> 
> The GeoProc?

Oh, the FP! That makes sense. I removed this code.

[egdaniel, 2016-07-13 19:27:27]

I still would like you to add a const char* distanceVectorName to GP EmitArgs
struct. If the pipeline says someone will use it, you will pass in the
distanceVectorName(), otherwise nullptr. The GPs will then key off this string
as to whether they should write this info or not.

https://codereview.chromium.org/2114993002/diff/160001/src/core/SkNormalSourc...
File src/core/SkNormalSource.cpp (right):

https://codereview.chromium.org/2114993002/diff/160001/src/core/SkNormalSourc...
src/core/SkNormalSource.cpp:33: // vector but the GP doesn't provide it.
Add to this comment that we don't need to adjust the key here since the use of a
given GP (through its class ID already in the key), will determine what code
gets emitted here.

https://codereview.chromium.org/2114993002/diff/160001/src/gpu/GrFragmentProc...
File src/gpu/GrFragmentProcessor.cpp (right):

https://codereview.chromium.org/2114993002/diff/160001/src/gpu/GrFragmentProc...
src/gpu/GrFragmentProcessor.cpp:167: fragBuilder->codeAppendf("%s.rgb *= %s.a;",
args.fOutputColor, args.fInputColor);
100 chars

https://codereview.chromium.org/2114993002/diff/160001/src/gpu/glsl/GrGLSLFra...
File src/gpu/glsl/GrGLSLFragmentShaderBuilder.cpp (right):

https://codereview.chromium.org/2114993002/diff/160001/src/gpu/glsl/GrGLSLFra...
src/gpu/glsl/GrGLSLFragmentShaderBuilder.cpp:193: return "outputDistanceVector";
lets call this fsDistanceVector. The fs to match what we do with the color
output name. Also this isn't really an output of the fragShader just a variable
used in it, so no need for 'output'

https://codereview.chromium.org/2114993002/diff/160001/src/gpu/glsl/GrGLSLPri...
File src/gpu/glsl/GrGLSLPrimitiveProcessor.h (right):

https://codereview.chromium.org/2114993002/diff/160001/src/gpu/glsl/GrGLSLPri...
src/gpu/glsl/GrGLSLPrimitiveProcessor.h:96: 
extra \n

https://codereview.chromium.org/2114993002/diff/160001/src/gpu/glsl/GrGLSLPri...
src/gpu/glsl/GrGLSLPrimitiveProcessor.h:108: 
extra \n

[dvonbeck, 2016-07-13 21:28:15]

https://codereview.chromium.org/2114993002/diff/160001/src/core/SkNormalSourc...
File src/core/SkNormalSource.cpp (right):

https://codereview.chromium.org/2114993002/diff/160001/src/core/SkNormalSourc...
src/core/SkNormalSource.cpp:33: // vector but the GP doesn't provide it.
On 2016/07/13 19:27:26, egdaniel wrote:
> Add to this comment that we don't need to adjust the key here since the use of
a
> given GP (through its class ID already in the key), will determine what code
> gets emitted here.

Done.

https://codereview.chromium.org/2114993002/diff/160001/src/gpu/GrFragmentProc...
File src/gpu/GrFragmentProcessor.cpp (right):

https://codereview.chromium.org/2114993002/diff/160001/src/gpu/GrFragmentProc...
src/gpu/GrFragmentProcessor.cpp:167: fragBuilder->codeAppendf("%s.rgb *= %s.a;",
args.fOutputColor, args.fInputColor);
On 2016/07/13 19:27:27, egdaniel wrote:
> 100 chars

Done.

https://codereview.chromium.org/2114993002/diff/160001/src/gpu/glsl/GrGLSLFra...
File src/gpu/glsl/GrGLSLFragmentShaderBuilder.cpp (right):

https://codereview.chromium.org/2114993002/diff/160001/src/gpu/glsl/GrGLSLFra...
src/gpu/glsl/GrGLSLFragmentShaderBuilder.cpp:193: return "outputDistanceVector";
On 2016/07/13 19:27:27, egdaniel wrote:
> lets call this fsDistanceVector. The fs to match what we do with the color
> output name. Also this isn't really an output of the fragShader just a
variable
> used in it, so no need for 'output'

Done.

https://codereview.chromium.org/2114993002/diff/160001/src/gpu/glsl/GrGLSLPri...
File src/gpu/glsl/GrGLSLPrimitiveProcessor.h (right):

https://codereview.chromium.org/2114993002/diff/160001/src/gpu/glsl/GrGLSLPri...
src/gpu/glsl/GrGLSLPrimitiveProcessor.h:96: 
On 2016/07/13 19:27:27, egdaniel wrote:
> extra \n

Done.

https://codereview.chromium.org/2114993002/diff/160001/src/gpu/glsl/GrGLSLPri...
src/gpu/glsl/GrGLSLPrimitiveProcessor.h:108: 
On 2016/07/13 19:27:27, egdaniel wrote:
> extra \n

Done.

[dvonbeck, 2016-07-13 21:32:25]

Description was changed from

==========
GrFP can express distance vector field req.,  program builder declares variable
for it

This update allows fragment processors to require a field of vectors to the
nearest edge. This requirement propagates:

- from child FPs to their parent
- from parent FPs to the GrPaint
- from GrPaint through the PipelineBuilder into GrPipeline
- acessed from GrPipeline by GrGLSLProgramBuilder

GrGLSL generates a variable for the distance vector and passes it down to the
GeometryProcessor->emitCode() method.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2114993002
==========

to

==========
GrFP can express distance vector field req.,  program builder declares variable
for it

This update allows fragment processors to require a field of vectors to the
nearest edge. This requirement propagates:

- from child FPs to their parent
- from parent FPs to the GrPaint
- from GrPaint through the PipelineBuilder into GrPipeline
- acessed from GrPipeline by GrGLSLProgramBuilder

GrGLSL generates a variable for the distance vector and passes it down to the
GeometryProcessor->emitCode() method.

This CL's base is the CL for adding the BevelNormalSource API:
https://codereview.chromium.org/2080993002

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2114993002
==========

[egdaniel, 2016-07-14 02:47:47]

https://codereview.chromium.org/2114993002/diff/180001/src/core/SkNormalSourc...
File src/core/SkNormalSource.cpp (right):

https://codereview.chromium.org/2114993002/diff/180001/src/core/SkNormalSourc...
src/core/SkNormalSource.cpp:42: void emitCode(EmitArgs& args) override {
lets mark emitCode and onSetData here as final so that we don't accidentally
override them in a sub class.

https://codereview.chromium.org/2114993002/diff/180001/src/core/SkNormalSourc...
src/core/SkNormalSource.cpp:63: virtual void onOnSetData(const
GrGLSLProgramDataManager& pdman, const GrProcessor& proc) = 0;
hmm this looks ugly. Maybe make it setNormalData?

https://codereview.chromium.org/2114993002/diff/180001/src/gpu/glsl/GrGLSLFra...
File src/gpu/glsl/GrGLSLFragmentShaderBuilder.h (right):

https://codereview.chromium.org/2114993002/diff/180001/src/gpu/glsl/GrGLSLFra...
src/gpu/glsl/GrGLSLFragmentShaderBuilder.h:58: virtual const char*
distanceVectorName() const = 0;
I think we can drop this down one level to grglslfpfragmentbuilder. The XP
should never need the distance vector. The gp probably doesn't need it either,
but we don't have anything that is FP only the GP builder inherits from the FP
one.

[dvonbeck, 2016-07-14 13:40:34]

https://codereview.chromium.org/2114993002/diff/180001/src/core/SkNormalSourc...
File src/core/SkNormalSource.cpp (right):

https://codereview.chromium.org/2114993002/diff/180001/src/core/SkNormalSourc...
src/core/SkNormalSource.cpp:42: void emitCode(EmitArgs& args) override {
On 2016/07/14 02:47:46, egdaniel wrote:
> lets mark emitCode and onSetData here as final so that we don't accidentally
> override them in a sub class.

Done.

https://codereview.chromium.org/2114993002/diff/180001/src/core/SkNormalSourc...
src/core/SkNormalSource.cpp:63: virtual void onOnSetData(const
GrGLSLProgramDataManager& pdman, const GrProcessor& proc) = 0;
On 2016/07/14 02:47:46, egdaniel wrote:
> hmm this looks ugly. Maybe make it setNormalData?

Done.

https://codereview.chromium.org/2114993002/diff/180001/src/gpu/glsl/GrGLSLFra...
File src/gpu/glsl/GrGLSLFragmentShaderBuilder.h (right):

https://codereview.chromium.org/2114993002/diff/180001/src/gpu/glsl/GrGLSLFra...
src/gpu/glsl/GrGLSLFragmentShaderBuilder.h:58: virtual const char*
distanceVectorName() const = 0;
On 2016/07/14 02:47:47, egdaniel wrote:
> I think we can drop this down one level to grglslfpfragmentbuilder. The XP
> should never need the distance vector. The gp probably doesn't need it either,
> but we don't have anything that is FP only the GP builder inherits from the FP
> one.

Done.

[egdaniel, 2016-07-26 13:48:25]

lgtm with the two nits

https://codereview.chromium.org/2114993002/diff/310001/src/gpu/GrPipeline.h
File src/gpu/GrPipeline.h (right):

https://codereview.chromium.org/2114993002/diff/310001/src/gpu/GrPipeline.h#n...
src/gpu/GrPipeline.h:170: 
extra \n

https://codereview.chromium.org/2114993002/diff/310001/src/gpu/GrPipelineBuil...
File src/gpu/GrPipelineBuilder.h (right):

https://codereview.chromium.org/2114993002/diff/310001/src/gpu/GrPipelineBuil...
src/gpu/GrPipelineBuilder.h:229: 
extra \n

[dvonbeck, 2016-07-26 14:38:27]

https://codereview.chromium.org/2114993002/diff/310001/src/gpu/GrPipeline.h
File src/gpu/GrPipeline.h (right):

https://codereview.chromium.org/2114993002/diff/310001/src/gpu/GrPipeline.h#n...
src/gpu/GrPipeline.h:170: 
On 2016/07/26 13:48:24, egdaniel wrote:
> extra \n

Done.

https://codereview.chromium.org/2114993002/diff/310001/src/gpu/GrPipelineBuil...
File src/gpu/GrPipelineBuilder.h (right):

https://codereview.chromium.org/2114993002/diff/310001/src/gpu/GrPipelineBuil...
src/gpu/GrPipelineBuilder.h:229: 
On 2016/07/26 13:48:25, egdaniel wrote:
> extra \n

Done.

[dvonbeck, 2016-07-28 16:14:42]

The CQ bit was checked by dvonbeck@google.com to run a CQ dry run

[commit-bot: I haz the power, 2016-07-28 16:14:49]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-28 17:15:30]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-28 17:15:31]

Dry run: This issue passed the CQ dry run.

[dvonbeck, 2016-07-28 17:20:34]

The CQ bit was checked by dvonbeck@google.com

[dvonbeck, 2016-07-28 17:20:35]

The patchset sent to the CQ was uploaded after l-g-t-m from egdaniel@google.com
Link to the patchset: https://codereview.chromium.org/2114993002/#ps370001
(title: "rebase")

[commit-bot: I haz the power, 2016-07-28 17:20:39]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-28 17:22:09]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-28 17:22:10]

Try jobs failed on following builders:
  skia_presubmit-Trybot on master.client.skia.fyi (JOB_FAILED,
http://build.chromium.org/p/client.skia.fyi/builders/skia_presubmit-Trybot/bu...)

[dvonbeck, 2016-07-28 18:00:34]

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

[bsalomon, 2016-07-29 16:30:27]

lgtm

[dvonbeck, 2016-07-29 16:32:08]

The CQ bit was checked by dvonbeck@google.com

[commit-bot: I haz the power, 2016-07-29 16:32:23]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-29 16:53:58]

Description was changed from

==========
GrFP can express distance vector field req.,  program builder declares variable
for it

This update allows fragment processors to require a field of vectors to the
nearest edge. This requirement propagates:

- from child FPs to their parent
- from parent FPs to the GrPaint
- from GrPaint through the PipelineBuilder into GrPipeline
- acessed from GrPipeline by GrGLSLProgramBuilder

GrGLSL generates a variable for the distance vector and passes it down to the
GeometryProcessor->emitCode() method.

This CL's base is the CL for adding the BevelNormalSource API:
https://codereview.chromium.org/2080993002

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2114993002
==========

to

==========
GrFP can express distance vector field req.,  program builder declares variable
for it

This update allows fragment processors to require a field of vectors to the
nearest edge. This requirement propagates:

- from child FPs to their parent
- from parent FPs to the GrPaint
- from GrPaint through the PipelineBuilder into GrPipeline
- acessed from GrPipeline by GrGLSLProgramBuilder

GrGLSL generates a variable for the distance vector and passes it down to the
GeometryProcessor->emitCode() method.

This CL's base is the CL for adding the BevelNormalSource API:
https://codereview.chromium.org/2080993002

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2114993002

Committed:
https://skia.googlesource.com/skia/+/4ef6dfa7089c092c67b0d5ec34e89c1e319af196
==========

[commit-bot: I haz the power, 2016-07-29 16:54:00]

Committed patchset #20 (id:370001) as
https://skia.googlesource.com/skia/+/4ef6dfa7089c092c67b0d5ec34e89c1e319af196

[mtklein, 2016-07-30 19:41:18]

A revert of this CL (patchset #20 id:370001) has been created in
https://codereview.chromium.org/2201613002/ by mtklein@google.com.

The reason for reverting is: UBSAN says we're reading a bad bool here:
bool usesDistanceVectorField() const { return fUsesDistanceVectorField; }

../../../include/gpu/GrPaint.h:83:51: runtime error: load of value 239, which is
not a valid value for type 'bool'
SUMMARY: AddressSanitizer: undefined-behavior
../../../include/gpu/GrPaint.h:83:51 in 


Seems likely also the root of Valgrind failure:
https://luci-milo.appspot.com/swarming/task/30522e4f2241cb10.

[dvonbeck, 2016-08-01 14:42:35]

Description was changed from

==========
GrFP can express distance vector field req.,  program builder declares variable
for it

This update allows fragment processors to require a field of vectors to the
nearest edge. This requirement propagates:

- from child FPs to their parent
- from parent FPs to the GrPaint
- from GrPaint through the PipelineBuilder into GrPipeline
- acessed from GrPipeline by GrGLSLProgramBuilder

GrGLSL generates a variable for the distance vector and passes it down to the
GeometryProcessor->emitCode() method.

This CL's base is the CL for adding the BevelNormalSource API:
https://codereview.chromium.org/2080993002

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2114993002

Committed:
https://skia.googlesource.com/skia/+/4ef6dfa7089c092c67b0d5ec34e89c1e319af196
==========

to

==========
GrFP can express distance vector field req.,  program builder declares variable
for it

This update allows fragment processors to require a field of vectors to the
nearest edge. This requirement propagates:

- from child FPs to their parent
- from parent FPs to the GrPaint
- from GrPaint through the PipelineBuilder into GrPipeline
- acessed from GrPipeline by GrGLSLProgramBuilder

GrGLSL generates a variable for the distance vector and passes it down to the
GeometryProcessor->emitCode() method.

This CL's base is the CL for adding the BevelNormalSource API:
https://codereview.chromium.org/2080993002

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2114993002

Committed:
https://skia.googlesource.com/skia/+/4ef6dfa7089c092c67b0d5ec34e89c1e319af196
==========

[dvonbeck, 2016-08-01 17:14:54]

The CQ bit was checked by dvonbeck@google.com to run a CQ dry run

[commit-bot: I haz the power, 2016-08-01 17:14:57]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-01 17:55:54]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-01 17:55:55]

Dry run: This issue passed the CQ dry run.

[dvonbeck, 2016-08-01 17:56:42]

The CQ bit was checked by dvonbeck@google.com

[dvonbeck, 2016-08-01 17:56:43]

The patchset sent to the CQ was uploaded after l-g-t-m from egdaniel@google.com,
bsalomon@google.com
Link to the patchset: https://codereview.chromium.org/2114993002/#ps390001
(title: "Fixed GrPaint unintialized bool")

[commit-bot: I haz the power, 2016-08-01 17:56:49]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-01 18:01:59]

Description was changed from

==========
GrFP can express distance vector field req.,  program builder declares variable
for it

This update allows fragment processors to require a field of vectors to the
nearest edge. This requirement propagates:

- from child FPs to their parent
- from parent FPs to the GrPaint
- from GrPaint through the PipelineBuilder into GrPipeline
- acessed from GrPipeline by GrGLSLProgramBuilder

GrGLSL generates a variable for the distance vector and passes it down to the
GeometryProcessor->emitCode() method.

This CL's base is the CL for adding the BevelNormalSource API:
https://codereview.chromium.org/2080993002

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2114993002

Committed:
https://skia.googlesource.com/skia/+/4ef6dfa7089c092c67b0d5ec34e89c1e319af196
==========

to

==========
GrFP can express distance vector field req.,  program builder declares variable
for it

This update allows fragment processors to require a field of vectors to the
nearest edge. This requirement propagates:

- from child FPs to their parent
- from parent FPs to the GrPaint
- from GrPaint through the PipelineBuilder into GrPipeline
- acessed from GrPipeline by GrGLSLProgramBuilder

GrGLSL generates a variable for the distance vector and passes it down to the
GeometryProcessor->emitCode() method.

This CL's base is the CL for adding the BevelNormalSource API:
https://codereview.chromium.org/2080993002

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2114993002

Committed:
https://skia.googlesource.com/skia/+/4ef6dfa7089c092c67b0d5ec34e89c1e319af196
Committed:
https://skia.googlesource.com/skia/+/9b03e7b29d963ea333a66dc5353e94f6391eb899
==========

[commit-bot: I haz the power, 2016-08-01 18:02:00]

Committed patchset #21 (id:390001) as
https://skia.googlesource.com/skia/+/9b03e7b29d963ea333a66dc5353e94f6391eb899