[SVGDom] Add <svg> viewBox support

[SVGDom] Add viewBox support

The main feature is <svg> viewBox and proper viewport support, but the CL
touches a few other things:

* refactor SkSVGRenderContext to auto-restore canvas state, and split the
  presentation bits into a separate CoW SkSVGPresentationContext

* introduce SkSVGNode::onPrepareToRender(), as a way for nodes to push their
  custom state before the actual onRender() call (instead of relying on
  non-virtual SkSVGNode to know about all possible state bits)

* add a "Type" suffix to SVG types, to disambiguate (e.g. SkSVGRectType vs.
  SkSVGRect)


R=robertphillips@google.com,stephana@google.com
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2222793002

Committed: https://skia.googlesource.com/skia/+/397a517d1a5774653fcdd08172f9a6b5eea67621

[f(malita), 2016-08-07 00:47:29]

Description was changed from

==========
[SVGDom] Add viewBox support

WIP

BUG=skia:
==========

to

==========
[SVGDom] Add viewBox support

WIP

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2222793002
==========

[f(malita), 2016-08-07 01:47:55]

Description was changed from

==========
[SVGDom] Add viewBox support

WIP

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2222793002
==========

to

==========
[SVGDom] Add viewBox support

The main feature is <svg> viewBox and proper viewport support, but the CL
touches a few other things:

* refactor SkSVGRenderContext to auto-restore canvas state, and split the
  presentation bits into a separate CoW SkSVGPresentationContext

* introduce SkSVGNode::onPrepareToRender(), as a way for nodes to push their
  custom state before the actual onRender() call (instead of relying on
  non-virtual SkSVGNode to know about all possible state bits)

* add a "Type" suffix to SVG types, to disambiguate (e.g. SkSVGRectType vs.
  SkSVGRect)


R=robertphillips@google.com,stephana@google.com
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2222793002
==========

[f(malita), 2016-08-07 01:47:55]

fmalita@chromium.org changed reviewers:
+ robertphillips@google.com, stephana@google.com

[f(malita), 2016-08-07 01:50:35]

The CQ bit was checked by fmalita@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-07 01:50:40]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-07 01:55:29]

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

[commit-bot: I haz the power, 2016-08-07 01:55:30]

Dry run: Try jobs failed on following builders:
  Build-Win-MSVC-x86-Debug-Trybot on master.client.skia.compile (JOB_FAILED,
http://build.chromium.org/p/client.skia.compile/builders/Build-Win-MSVC-x86-D...)

[f(malita), 2016-08-07 14:53:10]

The CQ bit was checked by fmalita@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-07 14:53:15]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-07 15:17:09]

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

[commit-bot: I haz the power, 2016-08-07 15:17:09]

Dry run: This issue passed the CQ dry run.

[robertphillips, 2016-08-08 13:55:28]

https://codereview.chromium.org/2222793002/diff/60001/experimental/svg/model/...
File experimental/svg/model/SkSVGAttributeParser.cpp (right):

https://codereview.chromium.org/2222793002/diff/60001/experimental/svg/model/...
experimental/svg/model/SkSVGAttributeParser.cpp:208: }
What happens on a partial parse that ends in an EOS?

https://codereview.chromium.org/2222793002/diff/60001/experimental/svg/model/...
File experimental/svg/model/SkSVGNode.h (right):

https://codereview.chromium.org/2222793002/diff/60001/experimental/svg/model/...
experimental/svg/model/SkSVGNode.h:44: // returning false.
// Returning false does what now?

https://codereview.chromium.org/2222793002/diff/60001/experimental/svg/model/...
File experimental/svg/model/SkSVGRenderContext.h (right):

https://codereview.chromium.org/2222793002/diff/60001/experimental/svg/model/...
experimental/svg/model/SkSVGRenderContext.h:88: SkCanvas*                       
             fCanvas;
// This is the save count on 'fCanvas' at construction time. A restoreToCount
will be issued on destruction

?

https://codereview.chromium.org/2222793002/diff/60001/experimental/svg/model/...
File experimental/svg/model/SkSVGSVG.h (right):

https://codereview.chromium.org/2222793002/diff/60001/experimental/svg/model/...
experimental/svg/model/SkSVGSVG.h:39: 
Are we getting much mileage out of this being lazy?

https://codereview.chromium.org/2222793002/diff/60001/experimental/svg/model/...
File experimental/svg/model/SkSVGTypes.h (right):

https://codereview.chromium.org/2222793002/diff/60001/experimental/svg/model/...
experimental/svg/model/SkSVGTypes.h:33: using SkSVGNumberType  =
SkSVGPrimitiveTypeWrapper<SkScalar>;
Is this going to initialize the SkRect as you want in the default ctor case?

https://codereview.chromium.org/2222793002/diff/60001/experimental/svg/model/...
File experimental/svg/model/SkSVGValue.h (right):

https://codereview.chromium.org/2222793002/diff/60001/experimental/svg/model/...
experimental/svg/model/SkSVGValue.h:67: using SkSVGTransformValue =
SkSVGWrapperValue<SkMatrix        , SkSVGValue::Type::kTransform>;
This doesn't get a kViewBox Type ?

[f(malita), 2016-08-08 17:13:29]

https://codereview.chromium.org/2222793002/diff/60001/experimental/svg/model/...
File experimental/svg/model/SkSVGAttributeParser.cpp (right):

https://codereview.chromium.org/2222793002/diff/60001/experimental/svg/model/...
experimental/svg/model/SkSVGAttributeParser.cpp:208: }
On 2016/08/08 13:55:28, robertphillips wrote:
> What happens on a partial parse that ends in an EOS?

Fixed.

https://codereview.chromium.org/2222793002/diff/60001/experimental/svg/model/...
File experimental/svg/model/SkSVGNode.h (right):

https://codereview.chromium.org/2222793002/diff/60001/experimental/svg/model/...
experimental/svg/model/SkSVGNode.h:44: // returning false.
On 2016/08/08 13:55:28, robertphillips wrote:
> // Returning false does what now?

Added more comments.

https://codereview.chromium.org/2222793002/diff/60001/experimental/svg/model/...
File experimental/svg/model/SkSVGRenderContext.h (right):

https://codereview.chromium.org/2222793002/diff/60001/experimental/svg/model/...
experimental/svg/model/SkSVGRenderContext.h:88: SkCanvas*                       
             fCanvas;
On 2016/08/08 13:55:28, robertphillips wrote:
> // This is the save count on 'fCanvas' at construction time. A restoreToCount
> will be issued on destruction
> 
> ?

Done.

https://codereview.chromium.org/2222793002/diff/60001/experimental/svg/model/...
File experimental/svg/model/SkSVGSVG.h (right):

https://codereview.chromium.org/2222793002/diff/60001/experimental/svg/model/...
experimental/svg/model/SkSVGSVG.h:39: 
On 2016/08/08 13:55:28, robertphillips wrote:
> Are we getting much mileage out of this being lazy?

It's just a convenient way to implement optional semantics (being able to
determine whether the attribute is set/present or not).  I expect we'll revisit
how we do this in general, to reduce the mem overhead (bitfield?).

https://codereview.chromium.org/2222793002/diff/60001/experimental/svg/model/...
File experimental/svg/model/SkSVGTypes.h (right):

https://codereview.chromium.org/2222793002/diff/60001/experimental/svg/model/...
experimental/svg/model/SkSVGTypes.h:33: using SkSVGNumberType  =
SkSVGPrimitiveTypeWrapper<SkScalar>;
On 2016/08/08 13:55:28, robertphillips wrote:
> Is this going to initialize the SkRect as you want in the default ctor case?

SkSVGViewBoxType attributes are safe because they're wrapped in SkTLazy and only
set when we actually parse a value.

But good point, we now lose default initialization for primitive wrappers.  I
think it's OK because all attributes should be either a) explicitly initialized
with a default value, or b) optional.

I'd really like to get rid of all default constructors here, but it'll take some
parser surgery.  WDYT?

https://codereview.chromium.org/2222793002/diff/60001/experimental/svg/model/...
File experimental/svg/model/SkSVGValue.h (right):

https://codereview.chromium.org/2222793002/diff/60001/experimental/svg/model/...
experimental/svg/model/SkSVGValue.h:67: using SkSVGTransformValue =
SkSVGWrapperValue<SkMatrix        , SkSVGValue::Type::kTransform>;
On 2016/08/08 13:55:28, robertphillips wrote:
> This doesn't get a kViewBox Type ?

Bah, good catch!  Done.

[f(malita), 2016-08-08 17:13:41]

The CQ bit was checked by fmalita@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-08 17:13:44]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-08 17:47:51]

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

[commit-bot: I haz the power, 2016-08-08 17:47:52]

Dry run: This issue passed the CQ dry run.

[robertphillips, 2016-08-08 17:56:10]

lgtm

https://codereview.chromium.org/2222793002/diff/80001/experimental/svg/model/...
File experimental/svg/model/SkSVGNode.h (right):

https://codereview.chromium.org/2222793002/diff/80001/experimental/svg/model/...
experimental/svg/model/SkSVGNode.h:45: // Implementations are expected to return
true if rendering is to continue, or false if
diabled ?

https://codereview.chromium.org/2222793002/diff/80001/experimental/svg/model/...
File experimental/svg/model/SkSVGRenderContext.cpp (right):

https://codereview.chromium.org/2222793002/diff/80001/experimental/svg/model/...
experimental/svg/model/SkSVGRenderContext.cpp:113: 
Depending on what semantics you expect, the new SkSVGRenderContext could have a
different fCanvasSaveCount from the original.

[f(malita), 2016-08-08 18:12:03]

https://codereview.chromium.org/2222793002/diff/80001/experimental/svg/model/...
File experimental/svg/model/SkSVGNode.h (right):

https://codereview.chromium.org/2222793002/diff/80001/experimental/svg/model/...
experimental/svg/model/SkSVGNode.h:45: // Implementations are expected to return
true if rendering is to continue, or false if
On 2016/08/08 17:56:10, robertphillips wrote:
> diabled ?

Done.

https://codereview.chromium.org/2222793002/diff/80001/experimental/svg/model/...
File experimental/svg/model/SkSVGRenderContext.cpp (right):

https://codereview.chromium.org/2222793002/diff/80001/experimental/svg/model/...
experimental/svg/model/SkSVGRenderContext.cpp:113: 
On 2016/08/08 17:56:10, robertphillips wrote:
> Depending on what semantics you expect, the new SkSVGRenderContext could have
a
> different fCanvasSaveCount from the original.

Indeed, that's intentional: the original save count reflects the state for
parent node rendering, we need to save the state upon entering the current node.

It would be clearer to keep the canvas/save count external, and just use a local
AutoCanvasRestore where needed.  but since we can e.g. apply transforms at
multiple levels (SkSVGSVG viewbox, SkSVGTransformable transform), the current
approach avoids some redundant save/restores.  Possibly not worth the complexity
in the long run.

[f(malita), 2016-08-08 18:13:56]

The CQ bit was checked by fmalita@chromium.org

[f(malita), 2016-08-08 18:13:57]

The patchset sent to the CQ was uploaded after l-g-t-m from
robertphillips@google.com
Link to the patchset: https://codereview.chromium.org/2222793002/#ps100001
(title: "typo")

[commit-bot: I haz the power, 2016-08-08 18:14:01]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-08 18:38:58]

Description was changed from

==========
[SVGDom] Add viewBox support

The main feature is <svg> viewBox and proper viewport support, but the CL
touches a few other things:

* refactor SkSVGRenderContext to auto-restore canvas state, and split the
  presentation bits into a separate CoW SkSVGPresentationContext

* introduce SkSVGNode::onPrepareToRender(), as a way for nodes to push their
  custom state before the actual onRender() call (instead of relying on
  non-virtual SkSVGNode to know about all possible state bits)

* add a "Type" suffix to SVG types, to disambiguate (e.g. SkSVGRectType vs.
  SkSVGRect)


R=robertphillips@google.com,stephana@google.com
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2222793002
==========

to

==========
[SVGDom] Add viewBox support

The main feature is <svg> viewBox and proper viewport support, but the CL
touches a few other things:

* refactor SkSVGRenderContext to auto-restore canvas state, and split the
  presentation bits into a separate CoW SkSVGPresentationContext

* introduce SkSVGNode::onPrepareToRender(), as a way for nodes to push their
  custom state before the actual onRender() call (instead of relying on
  non-virtual SkSVGNode to know about all possible state bits)

* add a "Type" suffix to SVG types, to disambiguate (e.g. SkSVGRectType vs.
  SkSVGRect)


R=robertphillips@google.com,stephana@google.com
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2222793002

Committed:
https://skia.googlesource.com/skia/+/397a517d1a5774653fcdd08172f9a6b5eea67621
==========

[commit-bot: I haz the power, 2016-08-08 18:39:00]

Committed patchset #6 (id:100001) as
https://skia.googlesource.com/skia/+/397a517d1a5774653fcdd08172f9a6b5eea67621