Note: works for well-formed poly-to-poly (perspective) transforms, but
doesn't support AE's degenerate corners semantics (concave/inverted
polys) at this point.
Bug: skia:10100
Change-Id: I5b3492b008302495b616867c139c6e5ad6dc57df
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/281595
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Florin Malita <fmalita@chromium.org>
Change-Id: I2d19c4f0ff1439dcd923a3064eb3ba78432a5113
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/281043
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
Lottie shapes (paths) are expressed as a sequence of vertices, where
each vertex has a
- position
- in-tangent control point (relative to position)
- out-tangent control point (relative to position)
A nice property of this representation, is that interpolation can be
performed independently on each scalar component.
This seems really close to what VectorAnimator is good at - so can we
shoe-horn shapes into vectors and drop the ShapeValue KeyframeAnimator
specialization? Yes, we can!
To support the conversion, we need to abstract out two aspects of the
VectorKeyframeAnimator builder:
- parsing the encoding length of a vector-representable object
- parsing the actual encoding data of a vector-representable object
(For current/regular vector values, the encoding length is the same as
the json array length, and the encoding data is just the array of json
numbers.)
Shapes are encoded as a sequence of 6 floats per vertex, plus an
additional/trailing boolean maker for the "closed shape" property:
[v0.posX, v0.posY, v0.inX, v0.inY, v0.outX, v0.outY, ..., closed_flag ]
(thus encoding_len == 6 * vertex_count + 1)
After we're done with parsing, animation/interpolation is handled
via existing VectorKeyframeAnimator - so we can remove
KeyframeAnimator<ShapeValue>.
Converting to SkPath is pretty much the same as for the previous
representation, except the input is now flattened.
Change-Id: I822797fceae561b52b709bf258163bbcc6b565fb
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/280898
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Florin Malita <fmalita@chromium.org>
This reverts commit e990fcc4b0.
Reason for revert: Build-Win-Clang-x86_64-Release-Shared
Original change's description:
> Enable deprecated-copy-dtor warning.
>
> In C++11 a user declared destructor still requires the compiler to
> implicitly default the copy constructor and copy assignment operator,
> but this is deprecated. Note that a user declared destructor suppresses
> the move constructor and move assignment operator; a user declared
> destructor exists if any '~Foo' method declaration appears inside
> 'class Foo' (even if defaulted); if the copy and move operations are the
> same then copy operations that take 'const Foo&' will do fine double
> duty as move operations.
>
> Clang seems to have an issue with this warning, in that it does not
> appear to distinguish between compiler defaulted and user defaulted
> destructors. As a result, it does not always warn when it should.
> There may yet be places in the code where a move operation is desired
> but may be suppressed because the implicitly defaulted moves are not
> declared because a destructor has been declared.
>
> This wraps dawn and shaderc configs in 'third_party' so that their
> headers will be included through '-isystem' in order to avoid the
> warnings generated by including their headers.
>
> Change-Id: I681524cd890d86305aa99b6b765a52113b4dfa4b
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/280406
> Reviewed-by: Mike Klein <mtklein@google.com>
> Reviewed-by: Brian Salomon <bsalomon@google.com>
> Commit-Queue: Ben Wagner <bungeman@google.com>
TBR=mtklein@google.com,bsalomon@google.com,bungeman@google.com
Change-Id: Icd6a2487637d21fcf7c4c7ab7cba7a8adfda5afd
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/280836
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
In C++11 a user declared destructor still requires the compiler to
implicitly default the copy constructor and copy assignment operator,
but this is deprecated. Note that a user declared destructor suppresses
the move constructor and move assignment operator; a user declared
destructor exists if any '~Foo' method declaration appears inside
'class Foo' (even if defaulted); if the copy and move operations are the
same then copy operations that take 'const Foo&' will do fine double
duty as move operations.
Clang seems to have an issue with this warning, in that it does not
appear to distinguish between compiler defaulted and user defaulted
destructors. As a result, it does not always warn when it should.
There may yet be places in the code where a move operation is desired
but may be suppressed because the implicitly defaulted moves are not
declared because a destructor has been declared.
This wraps dawn and shaderc configs in 'third_party' so that their
headers will be included through '-isystem' in order to avoid the
warnings generated by including their headers.
Change-Id: I681524cd890d86305aa99b6b765a52113b4dfa4b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/280406
Reviewed-by: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
Expand the core animator logic to return whether the computed value is
changing on each tick. Also rename tick/onTick -> seek/onSeek to better
reflect Skottie semantics.
This information allows us to skip adapter updates for static/hold
animation segments.
This effectively hoists some of the scene graph lazy-update logic to the
Skottie model level, and culls unneeded conversions (e.g. we were
converting ShapeValue -> SkPath on every tick, even when the shape was
not changing).
TBR=
Change-Id: I1ea4e19ae8f993d659826269de6b0465fec70189
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/279816
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Florin Malita <fmalita@chromium.org>
Bug: skia:10080
Change-Id: I936d6d696c86c50d5b51dc84894127c38ad753d4
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/279048
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Plumb layer style parsing, and extend existing DropShadowAdapter to
support both drop shadow style and drop shadow effect.
Change-Id: Id99a419dacd06dc38dc4cf84ff4ecb92218c45f7
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/279020
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Florin Malita <fmalita@chromium.org>
This makes the call sites a bit simpler, doesn't materially change
anything in an optimized build, allows NRVO, and generally fixes a
number of warnings in gcc 9 about pessimizing-move.
Change-Id: I0ea5f57db163425da728630bfa6c1add7c416bd7
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/278178
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Ben Wagner <bungeman@google.com>
Currently we're handling VectorValues via a generic animator => we use
vector<vector<float>> for storage. That's kinda clunky, especially for
small-size vectors (3d values, colors).
Introduce a more efficient VectorKeyframeAnimator:
- stores vector values in a contiguous/consolidated float array
- keyframes reference value offsets in storage
- fast/sk4f lerp impl
Change-Id: Ia9538068f2c722c2d2209f87e26564f0fe28ac31
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/277578
Commit-Queue: Florin Malita <fmalita@chromium.org>
Reviewed-by: Mike Klein <mtklein@google.com>
A significant number of spatial keyframes have trivial Bezier control
points - e.g. located on the linear interpolation segment. The
corresponding cubics have no effect and can be discarded.
Change-Id: I706546653c3621fd0d3eb9c285627ccd4d0bc549
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/276410
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Florin Malita <fmalita@chromium.org>
No need for an intermediate adapter object - just bind individual/scalar
fields using existing mechanisms.
No functional side effects.
TBR=
Change-Id: I16be769e5fb92dba0ebb6ce3b0584c5cdcc2b92c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/276215
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Florin Malita <fmalita@chromium.org>
AE discriminates [1] between basic 2-dimensional properties
(PropertyValueType.TwoD - e.g. scale), and spatial 2D properties
(PropertyValueType.TwoD_SPATIAL - e.g. position).
For the latter it provides additional keyframe controls (tangent in &
tangent out) to describe a non-linear interpolation path ("spatial
interpolation"). This composes on top of the usual temporal
interpolation (with its own optional cubic mapping).
To support spatial interpolation:
- introduce a new Skottie value type (Vec2Value), to represent
TwoD and TwoD_SPATIAL properties
- introduce a KeyframeAnimator specialization for Vec2Value, which
tracks per-keyframe tangent information
- for spatial keyframes, instantiate/store an SkContourMeasure, and
use instead of straight Vec2 LERP
- switch interesting 2D properties to the new value type (transform
position, anchor point, scale)
(we could look into separating TwoD/TwoD_SPATIAL if needed, but the new
specialization is already more efficient than the old
opaque-vector-with-late-binding approach)
[1] http://docs.aenhancers.com/properties/property/#property-propertyvaluetype
Change-Id: I0863fd970cec4c5ff15cf01b2fb5c6602a468179
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/274283
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Florin Malita <fmalita@chromium.org>
Since we can't use mask filters on layer paints any longer, refactor the
existing wipe effects to use explicit shader masking:
- remove SkSG::MaskFilterEffect - it no longer works
- replace with SkSG::MaskShaderEffect
- for atomic draws, apply the shader to the draw paint as
SkShader::Blend(kSrcIn, mask_shader)
- for isolated content, apply the mask as an extra pass
drawPaint(kDstIn, mask_shader) before restoring the layer
- refactor VenetianBlindsEffect, LinearWipeEffect and RadialWipeEffect
to use mask shaders
- additionally, refactor the RadialWipeEffect gradient to avoid using
a local shader matrix (does not compose correctly within the new
framework)
Everyone clear... do not touch the patient... BZZZT!
TBR=
Change-Id: I3a88da97a17b3b68812480cad5298b8778b6847c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/275694
Reviewed-by: Florin Malita <fmalita@chromium.org>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Florin Malita <fmalita@chromium.org>
Split the keyframe parsing logic into separate builder helpers.
No functional impact, this will facilitate some upcoming changes.
TBR=
Change-Id: I62a02a0ad90ddef572208f8714f22ae0a0b97023
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/276003
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Florin Malita <fmalita@chromium.org>
Implement all AE grouping modes: character/word/line/all.
-- character grouping was already supported (default mode)
-- for word and line grouping, expand the existing domain mapping logic
to also track cumulative advance and max(ascent) per span, then use
this info to compute anchor point boxes
-- for "all" grouping, the anchor point box coincides with the text box
(https://helpx.adobe.com/after-effects/using/animating-text.html#text_anchor_point_properties)
TBR=
Change-Id: I8564f1349d167d82c31862d8f7e57615cdae0dcf
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/274201
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Florin Malita <fmalita@chromium.org>
AE supports dashing all strokes. Dashes are specified as an arbitrary
number of intervals (alternating dash/gap) plus a start offset.
All values can be animated independently (but of course!).
- implement a SkSG dash effect (based on SkDashPathEffect)
- expand the shape builder logic to allow local geometry adjustments
(kind of a bummer that dashing is a stroke/paint property as opposed
to a geometry effect in AE)
Change-Id: Ic9ff35f2f9a552a3c26f9e1596ce58ad81f7ced5
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/274550
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Florin Malita <fmalita@chromium.org>
By default, per-character AE transforms are anchored on the glyph
baseline, mid-advance.
To support:
- extend SkottieShaper to track per-fragment ascent and advance
- adjust the fragment transform origin for (advance/2,0)
As an optimization, we only track the anchor point in the presence
of origin-dependent animators (scale & rotation ATM).
(note: the ascent info is going to be used in a follow up CL to support
relative anchor point adjustments)
Change-Id: I883a957028e624522fdf68a6b2fc44384dee18fe
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/273984
Commit-Queue: Florin Malita <fmalita@chromium.org>
Reviewed-by: Ben Wagner <bungeman@google.com>
In adition to transforms/opacity/etc, text animators can target
per-glyph opacity.
Change-Id: I6ab63a6e49a64beaf63fc955f0b672a5b8ba84ba
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/272886
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Florin Malita <fmalita@chromium.org>
When per-character 3D is enabled, text properties can be animated in
3 dimensions.
- position and scale become 3-value vectors
- in addition to existing "r" (really rz), rotation gains "rx" and "ry"
- instead of specializing for 3D, expand the existing structures to
handle both 3D and 2D modes
- also ensure that sksg::Transform does not flatten to SkMatrix
Change-Id: I426a7ee1ff38c1702deb85e9f1db80f6069f36d6
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/272648
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Florin Malita <fmalita@chromium.org>
Need to migrate clients from private/ to core/ include
Unexperimentalize concat44() methods on SkCanvas
Change-Id: I64b8816722a9d93316cb8b8691d2d9a3e36f167f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/272464
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Mike Reed <reed@google.com>
AE discards lines with baselines outside the paragraph box.
This aligns Skottie's behavior with AE for default/top-alignment
(but not for any of the custom vertical alignment modes).
Bug: skia:9933
Change-Id: Id0318f0744bf89580774e89494faf19bfb6f6d14
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/272376
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Florin Malita <fmalita@chromium.org>
This CL has a complicated back story, but it's concrete change is
simple, just turning the warning on and converting a bunch of
return foo;
to
return std::move(foo);
These changes are exclusively in places where RVO and NRVO do not apply,
so it should not conflict with warnings like -Wpessimizing-move.
Since C++11, when you return a named local and its type doesn't match
the declared return type exactly, there's an implicit std::move()
wrapped around the value (what I'm making explicit here) so the move
constructor gets an opportunity to take precedence over the copy
constructor. You can read about this implicit move here under the
section "automatic move from local variables and parameters":
https://en.cppreference.com/w/cpp/language/return#Notes.
This situation comes up for us with smart pointers: a function declares
its return type as std::unique_ptr<Base> or sk_sp<Base>, and we return a
std::unique_ptr<Impl> or sk_sp<Impl>. Those types don't match exactly,
so RVO and NRVO don't come into play. They've always been going through
move constructors, and that's not changed here, just made explicit.
There was apparently once a bug in the C++11 standard and compilers
implementing that which made these copy instead of move, and then this
sort of code would do a little unnecessary ref/unref dance for sk_sp,
and would entirely fail to compile for uncopyable std::unique_ptr.
These explicit moves ostensibly will make our code more compatible with
those older compilers.
That compatibility alone is, I think, a terrible reason to land this CL.
Like, actively bad. But... to balance that out, I think the explicit
std::move()s here actually help remind us that RVO/NRVO are not in play,
and remind us we're going to call the move constructor. So that C++11
standard bug becomes kind of useful for us, in that Clang added this
warning to catch it, and its fix improves readability.
So really read this all as, "warn about implicit std::move() on return".
In the end I think it's just about readability. I don't really hold any
hope out that we'll become compatible with those older compilers.
Bug: skia:9909
Change-Id: Id596e9261188b6f10e759906af6c95fe303f6ffe
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/271601
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Generally, keyframe values live in dedicated storage, and are tracked in
keyframes based on their index.
This separation is not necessary for float values, as their storage size
is the same as their index's:
- update keyframes to store value records (VRecs), which can hold
either external value indices or inline floats
- introduce a scalar animator specialization which operates on float
VRecs and doesn't require dedicated value storage
Change-Id: Icd8f1608c28c761303bdc44a23f562a2d2810d4f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/270844
Commit-Queue: Florin Malita <fmalita@chromium.org>
Reviewed-by: Mike Klein <mtklein@google.com>
For each Lottie keyframe, we currently store interpolation
*segments*:
{
t0, v0
t1, v1
cubic_mapper
}
This is quite redundant:
- kf(n).t1 == kf(n+1).t0 for all keyframes
- kf(n).v1 == kf(n+1).v0 for all non-constant keyframes
Refactor to store single keyframe records:
{
t, v
mapping
}
To identify constant keyframes, since we no longer store
explicit hard stops, we now tag each record with a "mapping"
selector:
0 -> constant keyframe
1 -> linear keyframe
> 1 -> cubic keyframe (adjusted cubic mapper index)
This reduces the storage size by 2/5, and yields overall cleaner
logic (as we're no longer back-filling info as we parse).
Also add a handful of unit tests to lock down limit semantics
(keyframe segments are left-inclusive/right-exclusive).
Change-Id: I3ab0e5568b83ab8536a7d326dbc07c4c455e978d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/270450
Commit-Queue: Florin Malita <fmalita@chromium.org>
Reviewed-by: Mike Reed <reed@google.com>
Also this contains a demonstration of how to implement this in CustomPropertyManager.
Change-Id: If4770e47b87ed76c98a85de3c235ab27c913dbc0
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/269696
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Florin Malita <fmalita@chromium.org>
Use std::min and std::max everywhere.
SkTPin still exists. We can't use std::clamp yet, and even when
we can, it has undefined behavior with NaN. SkTPin is written
to ensure that we return a value in the [lo, hi] range.
Change-Id: I506852a36e024ae405358d5078a872e2c77fa71e
Docs-Preview: https://skia.org/?cl=269357
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/269357
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Similar to existing ADBE Easy Levels2, but provides separate mapping
controls per channel.
Change-Id: Ibc58c58e1e8cb8793d6eb819998c1804ccbbf859
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/268936
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Florin Malita <fmalita@chromium.org>
Split off most shape layer components into own CUs (naming convention
following AE), and convert to new DiscardableAdapter pattern.
TBR=
Change-Id: Iba7800cff1998d3d7cf81dfd89b4193d02b59559
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/265147
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Florin Malita <fmalita@chromium.org>
Change-Id: I659552466940b76a339caaf124700303806fd082
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/265456
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
