Remove GrPipelineBuilder from getPathRenderer call

Remove GrPipelineBuilder from getPathRenderer call

Logically this CL:

Moves the PathRendererChain from GrContext to GrDrawManager
   - this was needed to untangled the Path-Chain/Renderer header mess
   - this entailed adding getDrawingMgr so the CMM could access the PathRenderingChain
   - this also entailed re-adding freeGpuResources to the GrDrawingMgr
Moves the CanDrawArgs struct up stack
Removes the GrPipelineBuilder from the CanDrawArgs struct

Committed: https://skia.googlesource.com/skia/+/687378229aecefc0ab7e639181593774ec8a4290

[robertphillips, 2015-10-27 19:47:50]

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

[robertphillips, 2015-10-27 19:47:50]

PTAL. I'm not crazy about this but I think it is marginally better than having
GrPipelineBuilder passed around.

[bsalomon, 2015-10-27 19:54:03]

https://codereview.chromium.org/1407883004/diff/1/include/gpu/GrContext.h
File include/gpu/GrContext.h (right):

https://codereview.chromium.org/1407883004/diff/1/include/gpu/GrContext.h#new...
include/gpu/GrContext.h:336: GrPathRenderer* getPathRenderer(
Maybe we should just pass the RT instead of the isMSAA thing?

Should we use a args struct here?

Is there a more semantic understanding of the stencilIsDisabled param, e.g.
callerWillStencil? I don't remember exactly why we need this.

[robertphillips, 2015-10-27 19:55:47]

Description was changed from

==========
Remove GrPipelineBuilder from canDrawPath call
==========

to

==========
Remove GrPipelineBuilder from getPathRenderercall
==========

[robertphillips, 2015-10-27 19:55:55]

Description was changed from

==========
Remove GrPipelineBuilder from getPathRenderercall
==========

to

==========
Remove GrPipelineBuilder from getPathRenderer call
==========

[robertphillips, 2015-10-29 14:33:26]

Description was changed from

==========
Remove GrPipelineBuilder from getPathRenderer call
==========

to

==========
Remove GrPipelineBuilder from getPathRenderer call

Logically this CL:

Moves the PathRendererChain from GrContext to GrDrawManager
Moves the CanDrawArgs struct up stack
Removes the GrPipelineBuilder from the CanDrawArgs struct
==========

[robertphillips, 2015-10-29 14:34:22]

Description was changed from

==========
Remove GrPipelineBuilder from getPathRenderer call

Logically this CL:

Moves the PathRendererChain from GrContext to GrDrawManager
Moves the CanDrawArgs struct up stack
Removes the GrPipelineBuilder from the CanDrawArgs struct
==========

to

==========
Remove GrPipelineBuilder from getPathRenderer call

Logically this CL:

Moves the PathRendererChain from GrContext to GrDrawManager
   - this entailed adding getDrawingMgr so the CMM could access the
PathRenderingChain
Moves the CanDrawArgs struct up stack
Removes the GrPipelineBuilder from the CanDrawArgs struct
==========

[robertphillips, 2015-10-29 14:39:28]

Description was changed from

==========
Remove GrPipelineBuilder from getPathRenderer call

Logically this CL:

Moves the PathRendererChain from GrContext to GrDrawManager
   - this entailed adding getDrawingMgr so the CMM could access the
PathRenderingChain
Moves the CanDrawArgs struct up stack
Removes the GrPipelineBuilder from the CanDrawArgs struct
==========

to

==========
Remove GrPipelineBuilder from getPathRenderer call

Logically this CL:

Moves the PathRendererChain from GrContext to GrDrawManager
   - this entailed adding getDrawingMgr so the CMM could access the
PathRenderingChain
   - this also entailed re-adding freeGpuResources to the GrDrawingMgr
Moves the CanDrawArgs struct up stack
Removes the GrPipelineBuilder from the CanDrawArgs struct
==========

[robertphillips, 2015-10-29 14:40:25]

Description was changed from

==========
Remove GrPipelineBuilder from getPathRenderer call

Logically this CL:

Moves the PathRendererChain from GrContext to GrDrawManager
   - this entailed adding getDrawingMgr so the CMM could access the
PathRenderingChain
   - this also entailed re-adding freeGpuResources to the GrDrawingMgr
Moves the CanDrawArgs struct up stack
Removes the GrPipelineBuilder from the CanDrawArgs struct
==========

to

==========
Remove GrPipelineBuilder from getPathRenderer call

Logically this CL:

Moves the PathRendererChain from GrContext to GrDrawManager
   - this was needed to untangled the Path-Chain/Renderer header mess
   - this entailed adding getDrawingMgr so the CMM could access the
PathRenderingChain
   - this also entailed re-adding freeGpuResources to the GrDrawingMgr
Moves the CanDrawArgs struct up stack
Removes the GrPipelineBuilder from the CanDrawArgs struct
==========

[robertphillips, 2015-10-29 14:51:32]

PTAL

https://codereview.chromium.org/1407883004/diff/1/include/gpu/GrContext.h
File include/gpu/GrContext.h (right):

https://codereview.chromium.org/1407883004/diff/1/include/gpu/GrContext.h#new...
include/gpu/GrContext.h:336: GrPathRenderer* getPathRenderer(
On 2015/10/27 19:54:03, bsalomon wrote:
> Maybe we should just pass the RT instead of the isMSAA thing?

I'm on the fence about this one. Passing the RT is clearer but the RT is
overkill for the usage.
 
> Should we use a args struct here?

Done.

> Is there a more semantic understanding of the stencilIsDisabled param, e.g.
> callerWillStencil? I don't remember exactly why we need this.

I think that will have to be a different CL. I've quickly looked at the code and
have come away un-enlightened (there both a kIsDisabled flag and a kNotDisabled
flag).

[bsalomon, 2015-10-29 14:58:10]

It all seems fine with one question: Do you really want to expose the drawing
manager from the context?

[robertphillips, 2015-10-29 17:15:46]

On 2015/10/29 14:58:10, bsalomon wrote:
> It all seems fine with one question: Do you really want to expose the drawing
> manager from the context?

Done. The drawingManager entry point is now private and the CMM is friended for
access.

[bsalomon, 2015-10-29 17:48:45]

lgtm

[robertphillips, 2015-10-29 17:50:33]

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

[commit-bot: I haz the power, 2015-10-29 17:50:43]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1407883004/50001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1407883004/50001

[commit-bot: I haz the power, 2015-10-29 18:05:28]

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

[commit-bot: I haz the power, 2015-10-29 18:05:29]

Dry run: This issue passed the CQ dry run.

[robertphillips, 2015-10-29 19:11:10]

The CQ bit was checked by robertphillips@google.com

[commit-bot: I haz the power, 2015-10-29 19:11:26]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1407883004/50001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1407883004/50001

[commit-bot: I haz the power, 2015-10-29 19:12:25]

Committed patchset #4 (id:50001) as
https://skia.googlesource.com/skia/+/687378229aecefc0ab7e639181593774ec8a4290