Fix SkStrokeRec == to report true for all fills

Fix SkStrokeRec == to report true for all fills

Fix SkStrokeRec == to report true for all fills, regardless
of the stale stroking data the object might contain.

Committed: https://skia.googlesource.com/skia/+/8f827fe44aad3c93638bc0f5dec32812c9ba2c98

[Kimmo Kinnunen, 2015-05-08 12:37:21]

kkinnunen@nvidia.com changed reviewers:
+ egdaniel@google.com, reed@google.com

[reed1, 2015-05-08 13:31:42]

I'm a little reluctant to change the interpretation of == to this more
functional one.

e.g. this sequence would seem odd.

    a == b
    a.setStyle(stroke)
    b.setStyle(stroke)
    a != b

Perhaps we can add a specialty predicate method that returns the sort of
functional equivalence you want?

[Kimmo Kinnunen, 2015-05-11 06:22:49]

On 2015/05/08 13:31:42, reed1 wrote:
> I'm a little reluctant to change the interpretation of == to this more
> functional one.
> 
> e.g. this sequence would seem odd.
> 
>     a == b
>     a.setStyle(stroke)
>     b.setStyle(stroke)
>     a != b


From academic argument point of view:
I think equally odd is that different stroke styles create different fills. The
source of oddity is more in setStrokeStyle, which does not reset the stroke
parameters to the defaults (or force them in the same setter).
Contrasting to: SkPaint is "container of properties" but SkStrokeRec seems to be
a "functional" object, (whatever that means). StrokeRec API implies you can not
individually control the properties anyway..

Also this creates the bug/oddity in serializing SkStrokeRec to a SkPaint and
back creates non-equal SkStrokeRec:

 a.applyToPaint(p)
 b(p)
 a != b

Also I fail to see the use-case from where it'd be useful to store those stale
parameters.

From practical point of view:
I'm of course happy with all solutions you're happy with. :)

> 
> Perhaps we can add a specialty predicate method that returns the sort of
> functional equivalence you want?

Done, how about now? (The operator== was originally implemented only for the
usecase in GrPath, so maybe there are not so many external users of the API?)

[Kimmo Kinnunen, 2015-05-11 11:19:55]

On 2015/05/11 06:22:49, Kimmo Kinnunen wrote:
> On 2015/05/08 13:31:42, reed1 wrote:
> > I'm a little reluctant to change the interpretation of == to this more
> > functional one.

> Contrasting to: SkPaint is "container of properties" but SkStrokeRec seems to
be
> a "functional" object, (whatever that means). 

.. and by "whatever that means" I meant to write "if I understand the meaning
correctly" :)

[egdaniel, 2015-05-12 13:31:00]

new version lgtm, but need mike for call on API

[reed1, 2015-05-12 13:31:32]

lgtm

[Kimmo Kinnunen, 2015-05-13 05:15:50]

The CQ bit was checked by kkinnunen@nvidia.com

[commit-bot: I haz the power, 2015-05-13 05:16:01]

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

[commit-bot: I haz the power, 2015-05-13 05:20:20]

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

[commit-bot: I haz the power, 2015-05-13 05:20:21]

Try jobs failed on following builders:
  Build-Win-MSVC-x86_64-Debug-Trybot on client.skia.compile (JOB_FAILED,
http://build.chromium.org/p/client.skia.compile/builders/Build-Win-MSVC-x86_6...)

[Kimmo Kinnunen, 2015-05-13 06:56:41]

The CQ bit was checked by kkinnunen@nvidia.com

[Kimmo Kinnunen, 2015-05-13 06:56:41]

The patchset sent to the CQ was uploaded after l-g-t-m from egdaniel@google.com,
reed@google.com
Link to the patchset: https://codereview.chromium.org/1130153002/#ps60001
(title: "the testcase had some doubles")

[commit-bot: I haz the power, 2015-05-13 06:56:49]

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

[commit-bot: I haz the power, 2015-05-13 07:02:33]

Committed patchset #4 (id:60001) as
https://skia.googlesource.com/skia/+/8f827fe44aad3c93638bc0f5dec32812c9ba2c98