Introduce SVGPathQuery to hold SVG path query methods

Introduce SVGPathQuery to hold SVG path query methods

Rename SVGPathTraversalStateBuilder.{cpp,h} to SVGPathQuery.{cpp,h}, and
similarly rename the class itself. Move the query methods in
SVGPathUtilities (getSVGPathSegAtLengthFromSVGPathByteStream,
getTotalLengthOfSVGPathByteStream, getPointAtLengthOfSVGPathByteStream)
to that class, shortening their names in the process.
Open-code the SVGPathParser driver to allow the general SVGPathConsumer
interface to be simplified - incrementPathSegmentCount and
continueConsuming are only used for path queries.

BUG=467592
Committed: https://crrev.com/97a8817d7e51850b1e40247490b91c6c484cc74a
Cr-Commit-Position: refs/heads/master@{#361351}

[fs, 2015-11-24 13:41:30]

Description was changed from

==========
Bundle the SVG path query methods

Rename SVGPathTraversalStateBuilder.{cpp,h} to SVGPathQuery.{cpp,h}, and
similarly rename the class itself. Move the query methods in
SVGPathUtilities (getSVGPathSegAtLengthFromSVGPathByteStream,
getTotalLengthOfSVGPathByteStream, getPointAtLengthOfSVGPathByteStream)
to that class, shortening their names in the process.
Open-code the SVGPathParser driver to allow the general SVGPathConsumer
interface to be simplified - incrementPathSegmentCount and
continueConsuming are only used for path queries.

BUG=467592
==========

to

==========
Introduce SVGPathQuery to hold SVG path query methods

Rename SVGPathTraversalStateBuilder.{cpp,h} to SVGPathQuery.{cpp,h}, and
similarly rename the class itself. Move the query methods in
SVGPathUtilities (getSVGPathSegAtLengthFromSVGPathByteStream,
getTotalLengthOfSVGPathByteStream, getPointAtLengthOfSVGPathByteStream)
to that class, shortening their names in the process.
Open-code the SVGPathParser driver to allow the general SVGPathConsumer
interface to be simplified - incrementPathSegmentCount and
continueConsuming are only used for path queries.

BUG=467592
==========

[fs, 2015-11-24 13:41:30]

fs@opera.com changed reviewers:
+ fmalita@chromium.org, pdr@chromium.org

[f(malita), 2015-11-24 14:22:40]

LGTM

https://codereview.chromium.org/1471943003/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/svg/SVGPathQuery.cpp (right):

https://codereview.chromium.org/1471943003/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/svg/SVGPathQuery.cpp:101:
traversalState.consumedSegment();
Could we get rid of consumedSegment by folding its logic into processSegment
(pass an hasMoreData arg, or indiscriminately inc the segment index)?

[fs, 2015-11-24 14:51:47]

https://codereview.chromium.org/1471943003/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/svg/SVGPathQuery.cpp (right):

https://codereview.chromium.org/1471943003/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/svg/SVGPathQuery.cpp:101:
traversalState.consumedSegment();
On 2015/11/24 at 14:22:40, f(malita) wrote:
> Could we get rid of consumedSegment by folding its logic into processSegment
(pass an hasMoreData arg, or indiscriminately inc the segment index)?

Done (the former, the latter would change semantics.)

[f(malita), 2015-11-24 15:03:51]

On 2015/11/24 14:51:47, fs wrote:
>
https://codereview.chromium.org/1471943003/diff/20001/third_party/WebKit/Sour...
> File third_party/WebKit/Source/core/svg/SVGPathQuery.cpp (right):
> 
>
https://codereview.chromium.org/1471943003/diff/20001/third_party/WebKit/Sour...
> third_party/WebKit/Source/core/svg/SVGPathQuery.cpp:101:
> traversalState.consumedSegment();
> On 2015/11/24 at 14:22:40, f(malita) wrote:
> > Could we get rid of consumedSegment by folding its logic into processSegment
> (pass an hasMoreData arg, or indiscriminately inc the segment index)?
> 
> Done (the former, the latter would change semantics.)

Thanks, LGTM++.

(I don't think it matters what happens to m_segmentIndex when hasMoreData ==
false, because we break the loop anyway.  But yeah, probably safer not to touch
it in this CL.)

[f(malita), 2015-11-24 15:05:54]

On 2015/11/24 15:03:51, f(malita) wrote:
> (I don't think it matters what happens to m_segmentIndex when hasMoreData ==
> false, because we break the loop anyway.  But yeah, probably safer not to
touch
> it in this CL.)

Never mind, I see traversalState outlives the call so it's likely important to
keep its index in bounds.

[fs, 2015-11-24 15:06:42]

On 2015/11/24 at 15:03:51, fmalita wrote:
> On 2015/11/24 14:51:47, fs wrote:
> >
https://codereview.chromium.org/1471943003/diff/20001/third_party/WebKit/Sour...
> > File third_party/WebKit/Source/core/svg/SVGPathQuery.cpp (right):
> > 
> >
https://codereview.chromium.org/1471943003/diff/20001/third_party/WebKit/Sour...
> > third_party/WebKit/Source/core/svg/SVGPathQuery.cpp:101:
> > traversalState.consumedSegment();
> > On 2015/11/24 at 14:22:40, f(malita) wrote:
> > > Could we get rid of consumedSegment by folding its logic into
processSegment
> > (pass an hasMoreData arg, or indiscriminately inc the segment index)?
> > 
> > Done (the former, the latter would change semantics.)
> 
> Thanks, LGTM++.
> 
> (I don't think it matters what happens to m_segmentIndex when hasMoreData ==
false, because we break the loop anyway.  But yeah, probably safer not to touch
it in this CL.)

(It's actually the return value for getPathSegIndexAtLength, so it does matter
in that case. Otherwise it doesn't, but an increment is not the world - even
less so now when it's no longer wrapped in a virtual...)

[fs, 2015-11-24 15:50:23]

The CQ bit was checked by fs@opera.com

[commit-bot: I haz the power, 2015-11-24 15:51:11]

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

[commit-bot: I haz the power, 2015-11-24 16:09:49]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2015-11-24 16:11:12]

Patchset 4 (id:??) landed as
https://crrev.com/97a8817d7e51850b1e40247490b91c6c484cc74a
Cr-Commit-Position: refs/heads/master@{#361351}