https://www.w3.org/TR/SVG11/struct.html#ImageElement
Supported reference types are data and non-local URIs. Resource loading
requires a ResourceProvider to have been set on the render context.
Not handled in this CL:
- preserveAspectRatio support
- SVG reference types (i.e. '<image xlink:href="file.svg" ...')
Bug: skia:10842
Change-Id: Ieec7569f60516b01fc847f4160d0733b1e3a1cf5
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/364576
Commit-Queue: Tyler Denniston <tdenniston@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Not currently used, but will be used for <image> support.
Change-Id: I3bbb79c88890100901a8b85734d3a4d86a618848
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/360605
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Tyler Denniston <tdenniston@google.com>
This CL adds a type enum to SkSVGIRI that will eventually be used to
distinguish between local fragments ('#frag-id'), non-local fragments
('/path/to/file.png') and data URIs ('data:image/png;base64,...').
To do so required a bit of refactoring of other types that previously
treated IRIs as basic strings. There are no functional changes in this
CL.
Change-Id: I8bf426f77c0779890bce74d2d243c09617f024c8
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/360601
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Tyler Denniston <tdenniston@google.com>
https://www.w3.org/TR/SVG11/filters.html#feSpecularLightingElement
Because a fair amount of functionality will be shared between
feSpecularLighting and feDiffuseLighting, this CL adds an intermediate
SkSVGFeLighting base class for common code.
The only light source type implemented in this CL is fePointLight, which
exercised by the filters-light-03 W3C test.
Bug: skia:10841
Change-Id: Icae26dedb1aae1cd25ba2db7c6468a243ebacbc5
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/359756
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Tyler Denniston <tdenniston@google.com>
https://www.w3.org/TR/SVG11/filters.html#LightSourceDefinitions
The three classes represent light source elements that will eventually
be used for feSpecularLighting and feDiffuseLighting. Currently they are
unused.
Also added the (currently unused) lighting-color presentation attribute.
Bug: skia:10841
Change-Id: Ic7824671662b8cd88cf627affc54173d5e881b7d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/359557
Commit-Queue: Tyler Denniston <tdenniston@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Enables use of text as a clip path.
Bug: skia:10840
Change-Id: I9de40e23696083e8cdd7e0b82221da3f3c36ac8b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/358533
Reviewed-by: Tyler Denniston <tdenniston@google.com>
Commit-Queue: Florin Malita <fmalita@google.com>
In preparation for text bounding box support, fission the actual
rendering phase from the shaping/alignment phase:
- rename onRenderText -> onShapeText
- introduce a ShapedTextCallback abstraction for consuming the result
of text processing
- relocate the final rendering step to a ShapedTextCallback impl
Bug: skia:10840
Change-Id: Ia8cc0d9a5a5484972a34042fd782f9e4fada6b12
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/358223
Commit-Queue: Florin Malita <fmalita@google.com>
Commit-Queue: Florin Malita <fmalita@chromium.org>
Reviewed-by: Tyler Denniston <tdenniston@google.com>
Per spec [1], unspecified inputs ('in', 'in2' attributes) have different
meaning depending on whether the referencing filter is the first in the
pipeline. This CL adds previous result tracking to the filter context
and handles unspecified values accordingly during input resolution.
[1] https://www.w3.org/TR/SVG11/filters.html#FilterPrimitiveInAttribute
Bug: skia:10841
Change-Id: I64618ad712979f6dd62adb4686085fe31618c3cb
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/357278
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Tyler Denniston <tdenniston@google.com>
Per spec (and empirically) <text> elements are not nestable (neither
directly or indirectly):
https://www.w3.org/TR/SVG11/intro.html#TermTextContentChildElement
Update the implementation to
- only bridge onRender -> onRenderText in the root SkSVGText
implementation
- disallow <text> elements as text container descendants
Change-Id: I07b3abaf943b820e01c88f78bddf7ce5970ee508
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/358220
Commit-Queue: Florin Malita <fmalita@google.com>
Reviewed-by: Tyler Denniston <tdenniston@google.com>
- Allow resolving inputs without modifying their colorspace
- Add helper to get the colorspace of a particular input
- Make resolveColorspace() virtual and add filter context to its
signature
Bug: skia:10841
Change-Id: I2e226ec26205f527c2d171140072f106ec35fbe0
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/356416
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Tyler Denniston <tdenniston@google.com>
Instead of attempting to keep fill & stroke SkPaints synchronized with
the current presentation attributes throughout the DAG walk, build the
SkPaints on the fly, only when needed.
This simplifies presentation attribute handling and enables further
/future refactoring.
Change-Id: I3791b4244530644e7e4b983d93b3c966ea7a1b22
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/355096
Commit-Queue: Florin Malita <fmalita@chromium.org>
Commit-Queue: Florin Malita <fmalita@google.com>
Reviewed-by: Tyler Denniston <tdenniston@google.com>
Property inheritance is supposed to follow the tree hierarchy, but we
implement it based on the render path.
One nasty side effect is when resolving IRI paint servers
(gradients, patterns), the referencing node properties get inherited
(leak) into the paint server fragment. E.g.
<pattern id="pat">
<rect fill="green"/>
</pattern>
<rect stroke="blue" fill="url(#pat)" stroke="blue"/>
The pattern subtree incorrectly inherits a blue stroke property from
the referencing node when we resolve the fill.
As a temporary (and imperfect) workaround, we can reset the presentation
context when resolving IRI paint servers.
Change-Id: Ia4a8a6199222820661f805c43340b5e16902feff
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/354668
Reviewed-by: Tyler Denniston <tdenniston@google.com>
Commit-Queue: Florin Malita <fmalita@google.com>
Note we are still not passing filters-blend-01-b because we don't yet
support feImage.
Bug: skia:10841
Change-Id: Ibca52c0e8e8d45e73473dea3b0252d6b81eaa584
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/354657
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Tyler Denniston <tdenniston@google.com>
When both filter and opacity attributes are set on a leaf node, the
opacity must be applied as a separate layer so that the results of the
filter are modified by the opacity. Previously in this circumstance we
were incorrectly applying the opacity to the paints only (without a
layer).
To illustrate:
<svg viewBox="0 0 1000 500" version="1.1"
xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink">
<defs>
<filter id="Green" x="0%" y="0%" width="100%" height="100%">
<feFlood flood-color="lime" flood-opacity="1" />
</filter>
</defs>
<rect x="30" y="20" width="400" height="100" fill="red" opacity="0.1"
filter="url(#Green)"/>
<g filter="url(#Green)">
<rect x="30" y="200" width="400" height="100" fill="red" opacity="0.1"/>
</g>
</svg>
The two rects should render differently. In the <g> case, the filter
output (opaque green) overrides the translucent red pixels of the rect.
In the <rect> case, the filter output overrides the translucent red
pixels with opaque green, but then is modified by the opacity on the
<rect>.
Relevant W3C test is filters-blend-01-b (and possibly others).
Change-Id: I165eed36c546f1f99457865cee58ee2b3bffe6f1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/354879
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Tyler Denniston <tdenniston@google.com>
Per spec, the explicit <mask> bounds [x,y,w,h] are used to also clip
the content (the actual mask geometry may extend beyond these bounds).
This clip is currently scoped such that it applies both to the mask
layer and the content layer. When the clip is not pixel-aligned,
we're anti-aliasing both layers' edges -- which darkens the composition
result (producing dark hairlines around the mask).
Push the clip down such that it applies to content only.
Change-Id: I32169e2b6dc9685e50a51c6b22cfaaac1a897239
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/354217
Commit-Queue: Florin Malita <fmalita@google.com>
Reviewed-by: Tyler Denniston <tdenniston@google.com>
From the spec [1], if any inputs of a filter are one of the standard
inputs (SourceGraphic, FillPaint, etc. -- anything except another
filter), then the default filter primitive subregion is equal to the
filter effect region.
[1] https://www.w3.org/TR/SVG11/filters.html#FilterPrimitiveSubRegion
Bug: skia:10841
Change-Id: I70632e5119861c46c9e48af944d2c7cfdfc3c351
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/354119
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Tyler Denniston <tdenniston@google.com>
Previously we were using fX and fY as the top left of the returned
bounds. We need instead to offset the referenced node's bounds by fX,
fY.
While I was here I updated the attribute parsing to the new form and
changed the type of fHref from SkSVGString to SkSVGIRI.
Change-Id: I4bfb91bca62e47f5dabfbb4aad48cbb301a7ea36
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/354118
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Tyler Denniston <tdenniston@google.com>
The input may contain invalid text constructs lacking a root <text> node
e.g. <svg><tspan>foo</tspan></svg>
Since we don't perform content model validation at the moment and text
contexts are only instantiated for root nodes, we must guard against
this case at render time.
Bug: oss-fuzz:29558
Change-Id: I7e39c1c4048900ce5becb3549802dc66bb1d242b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/353711
Commit-Queue: Florin Malita <fmalita@chromium.org>
Commit-Queue: Florin Malita <fmalita@google.com>
Reviewed-by: Tyler Denniston <tdenniston@google.com>
https://www.w3.org/TR/SVG11/masking.html#Masking
Implement masking based on a classic two-layers + kSrcIn blending
approach.
An additional layer is used to filter the mask content (but could be
avoided in a pinch -- see inline comments).
Also consolidate the objectBoundingBox rect resolution logic as
SkSVGRenderContext::resolveOBBRect().
Bug: skia:10842
Change-Id: I273318e97cc28d599d1ecf01706b6117eecb62d5
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/353631
Commit-Queue: Florin Malita <fmalita@chromium.org>
Commit-Queue: Florin Malita <fmalita@google.com>
Reviewed-by: Tyler Denniston <tdenniston@google.com>
This reverts commit 36acb7b10c.
Reason for revert: artifacts in 1010102 are expected
Original change's description:
> Revert "[svg] Perform colorspace conversions for filter effects"
>
> This reverts commit a0880eda22.
>
> Reason for revert: visual artifacts in 10-bit color depth (10-10-10-2)
>
> Original change's description:
> > [svg] Perform colorspace conversions for filter effects
> >
> > A filter effect can optionally be specified to operate in either sRGB
> > or linearRGB, according to the SVG spec:
> >
> > https://www.w3.org/TR/SVG11/painting.html#ColorInterpolationProperties
> >
> > This CL adds any necessary conversion steps (SkColorFilters) while
> > constructing the filter DAG. The default filter effect color space is
> > linearRGB. We should now be passing the filters-gauss-* W3C tests.
> >
> > Specific changes:
> > - Tag filter effect results with their colorspace when storing them in
> > the filter context map
> > - Add an SkColorFolor conversion step as necessary when resolving filter
> > effect inputs
> >
> > Bug: skia:10841
> > Change-Id: Ide12698ea64c4d40f09df93a60718788809086fa
> > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/353078
> > Commit-Queue: Tyler Denniston <tdenniston@google.com>
> > Reviewed-by: Florin Malita <fmalita@chromium.org>
>
> TBR=fmalita@chromium.org,tdenniston@google.com
>
> Change-Id: Id4a33c49643039cfb2d2867a1513e8ee1d7b181a
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: skia:10841
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/353630
> Reviewed-by: John Stiles <johnstiles@google.com>
> Commit-Queue: John Stiles <johnstiles@google.com>
TBR=fmalita@chromium.org,tdenniston@google.com,johnstiles@google.com
# Not skipping CQ checks because this is a reland.
Bug: skia:10841
Change-Id: Id6d9e01d9b18ebfb6f9a6cb74518ad5cd73ea00a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/353777
Reviewed-by: Tyler Denniston <tdenniston@google.com>
Commit-Queue: Tyler Denniston <tdenniston@google.com>
This reverts commit a0880eda22.
Reason for revert: visual artifacts in 10-bit color depth (10-10-10-2)
Original change's description:
> [svg] Perform colorspace conversions for filter effects
>
> A filter effect can optionally be specified to operate in either sRGB
> or linearRGB, according to the SVG spec:
>
> https://www.w3.org/TR/SVG11/painting.html#ColorInterpolationProperties
>
> This CL adds any necessary conversion steps (SkColorFilters) while
> constructing the filter DAG. The default filter effect color space is
> linearRGB. We should now be passing the filters-gauss-* W3C tests.
>
> Specific changes:
> - Tag filter effect results with their colorspace when storing them in
> the filter context map
> - Add an SkColorFolor conversion step as necessary when resolving filter
> effect inputs
>
> Bug: skia:10841
> Change-Id: Ide12698ea64c4d40f09df93a60718788809086fa
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/353078
> Commit-Queue: Tyler Denniston <tdenniston@google.com>
> Reviewed-by: Florin Malita <fmalita@chromium.org>
TBR=fmalita@chromium.org,tdenniston@google.com
Change-Id: Id4a33c49643039cfb2d2867a1513e8ee1d7b181a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:10841
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/353630
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
A filter effect can optionally be specified to operate in either sRGB
or linearRGB, according to the SVG spec:
https://www.w3.org/TR/SVG11/painting.html#ColorInterpolationProperties
This CL adds any necessary conversion steps (SkColorFilters) while
constructing the filter DAG. The default filter effect color space is
linearRGB. We should now be passing the filters-gauss-* W3C tests.
Specific changes:
- Tag filter effect results with their colorspace when storing them in
the filter context map
- Add an SkColorFolor conversion step as necessary when resolving filter
effect inputs
Bug: skia:10841
Change-Id: Ide12698ea64c4d40f09df93a60718788809086fa
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/353078
Commit-Queue: Tyler Denniston <tdenniston@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
The default colorspace for filter effects is linear RGB, as specified in
https://www.w3.org/TR/SVG11/painting.html#ColorInterpolationProperties.
Currently we perform all filtering in the destination colorspace. This
CL adds the new presentation attribute with the default setting
(according to the spec) of linear RGB.
This CL does not actually implement any colorspace transformations for
filters.
Bug: skia:10841
Change-Id: Id778ad3fa5cb6e0aed756584a50880edd9d82e2b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/352738
Commit-Queue: Tyler Denniston <tdenniston@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Introduce SkSVGMask and plumb related attributes.
Also consolidate the clip/mask/filter property types - they all support
the same values: <funciri>|none|inherit.
Bug: skia:10842
Change-Id: If45a75cccc19b84d6547237336fe5d562a85d594
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/353436
Commit-Queue: Florin Malita <fmalita@chromium.org>
Commit-Queue: Florin Malita <fmalita@google.com>
Reviewed-by: Tyler Denniston <tdenniston@google.com>
- introduce SkSVGTextPath and update the text render logic to
instantiate new SkSVGTextContexts in onRenderText() overrides
instead of renderText() root -- this is to observe spec semantics
[1] requiring <text> and <textPath> to always start a new chunk,
regardless of their relative nesting.
- expand SkSVGTextContext to also store PathData when used in the
scope of a textPath
- PathData caches SkContourMeasures, for path position lookup
- update flushChunk() to apply path glyph adjustments [2]:
* the horizontal glyph position (including relative offset dx),
adjusted for the glyph center yields a path offset
* if the offset is outside the path range, the glyph is skipped
* otherwise the position is determined based on the path matrix
at the computed offset
- to support the logic above, the chunk starting position is no
longer used as a global blob offset but instead is folded into
individual glyph RSXforms (and the blob always draws at {0,0})
[1] https://www.w3.org/TR/SVG11/text.html#TextLayout
[2] https://www.w3.org/TR/SVG11/text.html#TextpathLayoutRules
Bug: skia:10840
Change-Id: I462eada7c086646afdc1bc84f08ec2368613f1c0
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/349397
Commit-Queue: Florin Malita <fmalita@google.com>
Reviewed-by: Tyler Denniston <tdenniston@google.com>
This filter implementation should be complete, but note we are still
not quite passing the W3C filters-gauss-* tests because our filters
currently operate in sRGB and not linear RGB (which is quite noticable
in some of the blur tests).
Bug: skia:10841
Change-Id: I706cde879ef6eb47ce586279999536cf67237f13
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/352506
Commit-Queue: Tyler Denniston <tdenniston@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Also removed an erroneous call to mapToRect() when returning bounds
for SkSVGContainer. The contexts in which we access object bounds are
always such that any transforms have already been applied.
Change-Id: Ieac488e1699d3ebff56038d6ada36737291671eb
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/345117
Commit-Queue: Tyler Denniston <tdenniston@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Spec: https://www.w3.org/TR/SVG11/filters.html#FilterPrimitiveSubRegion
The filter primitive subregion restricts the output of a specific <fe*>
node in a filter DAG. By default it's equal to the union of subregions
of all input filters, or the filter region if no inputs exist. If
x/y/w/h are specified on the <fe*> node, those are used to bound the
primitive subregion instead.
In this CL:
- Implement the computation of the primitive subregion in
SkSVGFe::resolveFilterSubregion
- Add primitiveUnits to filter context
- Change result registration (by string ID) in filter context to include
the primitive subregion of that result. This is needed because filters
referencing previous results need access to those primitive subregions
to compute the union.
Bug: skia:10841
Change-Id: I66fbb4979e3c65cb5e5cc61f98286ec7ad023438
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/344666
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Tyler Denniston <tdenniston@google.com>
Implement support for text 'rotate' attribute:
https://www.w3.org/TR/SVG11/text.html#TSpanElementRotateAttribute.
Unlike other character-positioning attributes (x/y/dx/dy), rotate
- is not cumulative
- only applies to its respective node scope (does not affect other
fragments in the current chunk)
- has different padding semantics: if there are fewer rotate
values than characters, the remaining characters use the last
specified value from the closest ancestor
To the last point, we now have to discriminate three states:
- unspecified (default -> 0)
- explicit value for the given character index
- implicit value (last value in the closest ancestor)
Local implicit values override implicit ancestor values -- but not
explicit ancestor values.
High level changes:
- plumb 'rotate' attribute
- expand per-character position info (ShapeBuffer) to include rotation
- expand per-glyph position info (RunRec) to include rotation
- expand PosAttrs to include rotation and add specific inheritance
rules (see above)
- pass computed rotation values to RSX blob buffers
Bug: skia:10840
Change-Id: Ia19ec5e8bb6fea06d49a9bd72ace575c2ffd100e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/348877
Commit-Queue: Florin Malita <fmalita@google.com>
Reviewed-by: Tyler Denniston <tdenniston@google.com>
