experiment with zero-length round capped line segments

experiment with zero-length round capped line segments

If the endcap is not butt, draw the endcaps even when the line
has zero length.

If the dash length is zero, generate a zero length line segment.

Treat a move followed by a close as a move followed by a zero-length
line.

R=reed@google.com,schenney@google.com
BUG=422974
Committed: https://skia.googlesource.com/skia/+/dd3c165828fffb369d0f4b13b48381169a0249a9

[caryclark, 2015-08-21 13:08:39]

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

[commit-bot: I haz the power, 2015-08-21 13:08:48]

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

[caryclark, 2015-08-21 13:10:49]

Stephen: Please take a look. I'm especially interested if the GM correctly tests
the need of the SVG engine to solve this bug.

The way butt caps are checked for in this CL is clunky -- maybe there's some
better way to get that info to the stroker.

[commit-bot: I haz the power, 2015-08-21 13:15:29]

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

[commit-bot: I haz the power, 2015-08-21 13:15:29]

Dry run: This issue passed the CQ dry run.

[Stephen Chennney, 2015-08-21 14:15:02]

schenney@chromium.org changed reviewers:
+ schenney@chromium.org

[Stephen Chennney, 2015-08-21 14:15:02]

The test covers the SVG case for round caps. There's also the square cap case
but I understand that's a distinct issue.

I can't comment on the stroking code.

[Stephen Chennney, 2015-08-21 14:15:21]

https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/stroke-linecap

[caryclark, 2015-08-21 14:31:55]

On 2015/08/21 14:15:02, Stephen Chenney wrote:
> The test covers the SVG case for round caps. There's also the square cap case
> but I understand that's a distinct issue.
> 
> I can't comment on the stroking code.

I believe the square cap will work as well. I'll add that variant to the gm.

[reed1, 2015-08-21 15:26:55]

Definitely want to capture the CL's documentation about our behaviors in these
various scenarios somewhere (SkPath.h ?)

https://codereview.chromium.org/1309753002/diff/20001/src/core/SkPathMeasure.cpp
File src/core/SkPathMeasure.cpp (right):

https://codereview.chromium.org/1309753002/diff/20001/src/core/SkPathMeasure....
src/core/SkPathMeasure.cpp:317: SkPoint lastPt;
Perhaps a comment about what might cause this, and why we want to add a lineTo?

https://codereview.chromium.org/1309753002/diff/20001/src/core/SkStroke.cpp
File src/core/SkStroke.cpp (right):

https://codereview.chromium.org/1309753002/diff/20001/src/core/SkStroke.cpp#n...
src/core/SkStroke.cpp:251: normal->set(fRadius, 0);
Add comment?

e.g.

// We cannot determine an orientation, but we have real caps, so we default to
upright-axis-aligned as our "default" orientation.

https://codereview.chromium.org/1309753002/diff/20001/src/core/SkStroke.cpp#n...
src/core/SkStroke.cpp:1345: if (stroker.hasOnlyMoveTo() && SkPaint::kButt_Cap !=
this->getCap()) {
Perhaps the same comment (or similar) to what we have in PathMeasure, as it
seems this is a similar heuristic response to an "empty" segment.

[caryclark, 2015-08-21 15:52:45]

Done

[caryclark, 2015-08-21 15:52:56]

https://codereview.chromium.org/1309753002/diff/20001/src/core/SkPathMeasure.cpp
File src/core/SkPathMeasure.cpp (right):

https://codereview.chromium.org/1309753002/diff/20001/src/core/SkPathMeasure....
src/core/SkPathMeasure.cpp:317: SkPoint lastPt;
On 2015/08/21 15:26:55, reed1 wrote:
> Perhaps a comment about what might cause this, and why we want to add a
lineTo?

Done.

https://codereview.chromium.org/1309753002/diff/20001/src/core/SkStroke.cpp
File src/core/SkStroke.cpp (right):

https://codereview.chromium.org/1309753002/diff/20001/src/core/SkStroke.cpp#n...
src/core/SkStroke.cpp:251: normal->set(fRadius, 0);
On 2015/08/21 15:26:55, reed1 wrote:
> Add comment?
> 
> e.g.
> 
> // We cannot determine an orientation, but we have real caps, so we default to
> upright-axis-aligned as our "default" orientation.

Done.

https://codereview.chromium.org/1309753002/diff/20001/src/core/SkStroke.cpp#n...
src/core/SkStroke.cpp:1345: if (stroker.hasOnlyMoveTo() && SkPaint::kButt_Cap !=
this->getCap()) {
On 2015/08/21 15:26:55, reed1 wrote:
> Perhaps the same comment (or similar) to what we have in PathMeasure, as it
> seems this is a similar heuristic response to an "empty" segment.

Done.

[reed1, 2015-08-21 20:11:07]

lgtm

[caryclark, 2015-08-21 20:20:47]

The CQ bit was checked by caryclark@google.com

[commit-bot: I haz the power, 2015-08-21 20:21:00]

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

[commit-bot: I haz the power, 2015-08-21 20:27:41]

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

[caryclark, 2015-08-21 20:46:44]

A revert of this CL (patchset #4 id:60001) has been created in
https://codereview.chromium.org/1304163008/ by caryclark@google.com.

The reason for reverting is: More GMs changed than I expected. Will probably
affect layout tests as well; reverting until I can verify that the changes are
correct..