Move segment mask from SkPath to SkPathRef

The old omnibus CL (https://codereview.chromium.org/25787002/) has gotten too far out of date. This calves off just the "fSegmentMask" portion.

[bsalomon, 2013-12-09 16:16:04]

https://codereview.chromium.org/105083003/diff/20001/include/core/SkPathRef.h
File include/core/SkPathRef.h (right):

https://codereview.chromium.org/105083003/diff/20001/include/core/SkPathRef.h...
include/core/SkPathRef.h:77: SkPoint* growForLines(int numLines) { return
fPathRef->growForLines(numLines); }
This feels a little weirdly specialized in SkPathRef's interface. Is it hard to
preserve addPoly performance if it was growForRepeatedVerb(Verb, n)? (perhaps
with a better name).

[robertphillips, 2013-12-09 19:01:51]

PTAL

https://codereview.chromium.org/105083003/diff/20001/include/core/SkPathRef.h
File include/core/SkPathRef.h (right):

https://codereview.chromium.org/105083003/diff/20001/include/core/SkPathRef.h...
include/core/SkPathRef.h:77: SkPoint* growForLines(int numLines) { return
fPathRef->growForLines(numLines); }
On 2013/12/09 16:16:04, bsalomon wrote:
> This feels a little weirdly specialized in SkPathRef's interface. Is it hard
to
> preserve addPoly performance if it was growForRepeatedVerb(Verb, n)? (perhaps
> with a better name).

Done.

[bsalomon, 2013-12-09 20:51:21]

https://codereview.chromium.org/105083003/diff/40001/include/core/SkPathRef.h
File include/core/SkPathRef.h (right):

https://codereview.chromium.org/105083003/diff/40001/include/core/SkPathRef.h...
include/core/SkPathRef.h:78: SkPoint* growForRepeatedVerb(int /*SkPath::Verb*/
verb, int numVbs) {
One more request around this:

Since this is public and currently can leave the PathRef in an inconsistent
state WRT to the number of allocated conic weights, can we change

SkPoint* growForRepeatedVerb(int /*SkPath::Verb*/ verb, int numVbs)

--to-->

SkPoint* growForRepeatedVerb(int /*SkPath::Verb*/ verb, int numVbs, SkScalar**
weights = NULL)

and have it bump the weights array (on behalf of growForConics)?

[robertphillips, 2013-12-10 15:30:51]

PTAL

https://codereview.chromium.org/105083003/diff/40001/include/core/SkPathRef.h
File include/core/SkPathRef.h (right):

https://codereview.chromium.org/105083003/diff/40001/include/core/SkPathRef.h...
include/core/SkPathRef.h:78: SkPoint* growForRepeatedVerb(int /*SkPath::Verb*/
verb, int numVbs) {
On 2013/12/09 20:51:21, bsalomon wrote:
> One more request around this:
> 
> Since this is public and currently can leave the PathRef in an inconsistent
> state WRT to the number of allocated conic weights, can we change
> 
> SkPoint* growForRepeatedVerb(int /*SkPath::Verb*/ verb, int numVbs)
> 
> --to-->
> 
> SkPoint* growForRepeatedVerb(int /*SkPath::Verb*/ verb, int numVbs, SkScalar**
> weights = NULL)
> 
> and have it bump the weights array (on behalf of growForConics)?

Done.

[bsalomon, 2013-12-10 20:10:11]

https://codereview.chromium.org/105083003/diff/80001/src/core/SkPathRef.cpp
File src/core/SkPathRef.cpp (right):

https://codereview.chromium.org/105083003/diff/80001/src/core/SkPathRef.cpp#n...
src/core/SkPathRef.cpp:292: SkPoint* SkPathRef::growForRepeatedVerb(int
/*SkPath::Verb*/ verb,
It seems a little odd that we return a pointer for the pts but take an array for
the weights rather than also returning a pointer. Is there a reason for that?

[robertphillips, 2013-12-12 13:59:52]

PTAL

https://codereview.chromium.org/105083003/diff/80001/src/core/SkPathRef.cpp
File src/core/SkPathRef.cpp (right):

https://codereview.chromium.org/105083003/diff/80001/src/core/SkPathRef.cpp#n...
src/core/SkPathRef.cpp:292: SkPoint* SkPathRef::growForRepeatedVerb(int
/*SkPath::Verb*/ verb,
Was just matching push style interface of growForVerb.

[bsalomon, 2013-12-12 17:57:09]

https://codereview.chromium.org/105083003/diff/80001/src/core/SkPathRef.cpp
File src/core/SkPathRef.cpp (right):

https://codereview.chromium.org/105083003/diff/80001/src/core/SkPathRef.cpp#n...
src/core/SkPathRef.cpp:292: SkPoint* SkPathRef::growForRepeatedVerb(int
/*SkPath::Verb*/ verb,
On 2013/12/12 13:59:53, robertphillips wrote:
> Was just matching push style interface of growForVerb.
I see.. I still think the new signature is slightly preferable. It can be used
whether or not the caller already has the weights in a contiguous array. lgtm

[robertphillips, 2013-12-12 23:04:28]

committed as r12660