Move more of SkPath into SkPathRef

This CL moves more fields from SkPath into SkPathRef. This is in support of "Stateful PathRenderer implementation" https://codereview.chromium.org/23926019/

[caryclark, 2013-10-03 20:36:14]

I apologize in advance for yelling at Robert about this, but I really, really
don't like this change.

It looks like a lot of churn to make PathRef contain all of the data in Path
instead of removing the fill type from Path. 

I'm sure that cooler heads will prevail.

https://codereview.chromium.org/25787002/diff/8001/include/core/SkPath.h
File include/core/SkPath.h (right):

https://codereview.chromium.org/25787002/diff/8001/include/core/SkPath.h#newc...
include/core/SkPath.h:101: kConcave_Convexity = SkPathRef::kConcave_Convexity
I don't agree with exposing the implementation in path ref unnecessarily here. I
would prefer to see compile time asserts in the implementation of path ref that
ensures that the two enums have identical values.

https://codereview.chromium.org/25787002/diff/8001/include/core/SkPath.h#newc...
include/core/SkPath.h:139: return SkPathRef::kConvex_Convexity ==
this->getConvexity();
why is this change needed? Isn't the contract that SkPath convexity enums must
equal SkPathRef convexity enums?

https://codereview.chromium.org/25787002/diff/8001/include/core/SkPath.h#newc...
include/core/SkPath.h:500: kCCW_Direction     = SkPathRef::kCCW_Direction,
same feedback as convexity change above; would prefer to see compile time
asserts verifying equality

https://codereview.chromium.org/25787002/diff/8001/include/core/SkPath.h#newc...
include/core/SkPath.h:508: return (Direction)
SkPathRef::OppositeDirection((SkPathRef::Direction)dir);
you have static casts in similar changes above

https://codereview.chromium.org/25787002/diff/8001/include/core/SkPath.h#newc...
include/core/SkPath.h:551: return
fPathRef->cheapComputeDirection((SkPathRef::Direction*) dir);
static cast

https://codereview.chromium.org/25787002/diff/8001/include/core/SkPath.h#newc...
include/core/SkPath.h:781: kCubic_SegmentMask  = SkPathRef::kCubic_SegmentMask,
Additionally, this change makes Skia harder to use. I have to look in two places
to associate debugging values with what they do.

https://codereview.chromium.org/25787002/diff/8001/include/core/SkPath.h#newc...
include/core/SkPath.h:798: kDone_Verb  = SkPathRef::kDone_Verb,  //!< iter.next
returns 0 points
another place to have compile time asserts

[bsalomon, 2013-10-03 20:40:23]

https://codereview.chromium.org/25787002/diff/8001/include/core/SkPath.h
File include/core/SkPath.h (right):

https://codereview.chromium.org/25787002/diff/8001/include/core/SkPath.h#newc...
include/core/SkPath.h:101: kConcave_Convexity = SkPathRef::kConcave_Convexity
On 2013/10/03 20:36:15, caryclark wrote:
> I don't agree with exposing the implementation in path ref unnecessarily here.
I
> would prefer to see compile time asserts in the implementation of path ref
that
> ensures that the two enums have identical values.

Would it make sense to promote Convexity to SkConvexity (that is, make it global
in some public header)? Then we wouldn't need two versions of the same enum.

Same for the other enums, though I'm less enthusiastic about promoting Verb out
of SkPath.

[robertphillips, 2014-01-24 17:53:48]

This CL has (so far) been split into:

Move fIsOval from SkPath to SkPathRef      -
https://codereview.chromium.org/89123002/
Move segment mask from SkPath to SkPathRef -
https://codereview.chromium.org/105083003/
Improved SkPathRef interface security      -
https://codereview.chromium.org/115323004/
Move fLastMoveToIndex from SkPath to SkPathRef -
https://codereview.chromium.org/146913002/