Note to the reviewer: Look at tests/util.js first and then
look at the others. Gerrit lets you ignore whitespace changes,
which I would recommend for this.
This emulates tests on the C++ side and dramatically reduces
boilerplate on the test code.
This also uses the beforeEach(async () => {}) trick to save
a lot of promise resolutions before each tests.
I try to clean up the style a bit as I go, seriously thinking
about adding eslint for at least the tests.
Change-Id: Iced4abb57f66572035ab5d1a54b374055e8aaa58
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/281439
Reviewed-by: Joe Gregorio <jcgregorio@google.com>
The CheckGeneratedFiles bot only required rewriting
.gn files, while the presubmit wants both .gn and .gni files.
It also appears that the #includes rewrite script runs on
both the presubmit and CheckGeneratedFiles bots.
These presubmits run on the CQ before landing right?
If so, no need for them in the CheckGeneratedFIles bot at all.
And of course, format .gni files.
Change-Id: Icd4526d62f85088862ad93566cc9ace11dc3e33f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/281505
Reviewed-by: Eric Boren <borenet@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
This means we take DOMMatrix everywhere now.
This reduced the *_makeShader benchmark by ~25% (4 us -> 3 us)
and cleaned up several callsites.
Trimming this down saves ~3kb in uncompressed code size.
Change-Id: Ie677c7ebb7bc97ed8cd4d4851a039b78b6f8079d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/281018
Reviewed-by: Mike Reed <reed@google.com>
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>
This does a head to head comparison for our JS-implemented
SkMatrix (DOMMatrix is tens of times slower) and adds support.
There are a few APIs (e.g. on Canvas) that don't yet support this.
This is because I want to experiment with the speed difference
between SimpleMatrix and emscripten's bindings and us just allocating
an array for the user on the WASM heap.
Change-Id: I47086dd6b40cbd522c6b85e5f9b1a7e819f54f9d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/280957
Reviewed-by: Kevin Lubick <kjlubick@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>
Unfortunately in clang 'deprecated' is both a set of warnings (at least
one of which we don't want) and a group of warnings (most of which we do
want). Leave the top level disabled, but re-enable all the warnings in
the group.
Most of the code changes are for the deprecated-copy diagnostic. In
C++11 implementing a copy constructor xor copy assignment operator
the default implementation of the other is still required to be the
default but is deprecated (the compiler can warn against doing this).
The idea is that if there was a need for a non-default copy constructor
or copy assignment operator then both should be implemented explicitly,
since it is unlikely that the default will do what is expected.
Note that the deprecated-copy-dtor has not yet been enabled as there
will need to be a lot more work to enable this diagnostic. Similar to
deprecated-copy, in C++11 when implementing a destructor the copy
constructor and copy assignment operator are still defaulted if not
declared, but this is also deprecated. The idea here is that if some
special handling is needed to destroy the object there is probably some
need to do something non-trivial when copying the object (or copying
should be disallowed).
Also, there are still some deprecated-declarations to clean up on
Android and Mac.
Change-Id: I5fc4b62713220e6f7d3724fd7342b4c8c74a3c67
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/278916
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
This is a reland of 4e79b6730d
Original change's description:
> Switch to using a Float32Array (bound as value array) for color.
>
> Change-Id: I1bcca931954b1399c79f4074a3d57a68847ac785
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/276757
> Commit-Queue: Nathaniel Nifong <nifong@google.com>
> Reviewed-by: Kevin Lubick <kjlubick@google.com>
Change-Id: If6b9097b2fcd6b9dbf75c6dd22138e0b2531e70d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/278780
Commit-Queue: Nathaniel Nifong <nifong@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
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>
Adds a "viewer" option to the build system that brings in tooling code
and sample code. Adds a very simple "MakeSlide" binding that knows
how to create the WavyPathText sample slide. Adds viewer.html with
code to animate viewer slides.
This can hopefully be the starting point for future work on bringing
viewer to CanvasKit.
Change-Id: Ia26e08726384b40b3f544fe8254f430dc9db08db
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/278892
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Commit-Queue: Chris Dalton <csmartdalton@google.com>
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 reverts commit 4e79b6730d.
Reason for revert: Bad canvaskit GM images
Original change's description:
> Switch to using a Float32Array (bound as value array) for color.
>
> Change-Id: I1bcca931954b1399c79f4074a3d57a68847ac785
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/276757
> Commit-Queue: Nathaniel Nifong <nifong@google.com>
> Reviewed-by: Kevin Lubick <kjlubick@google.com>
TBR=kjlubick@google.com,nifong@google.com
Change-Id: I2f5e995ccee415a49f813b5ba61c095acbc445b5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/278766
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
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>
Updated to use sentinel GL context even when GL backend is not built.
This reverts commit 1171d314ef.
Change-Id: Ia94bbe4865ddd4e898446c13886877c539f0eb0b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/277976
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
By default, we just ship with PNG encoding/decoding and
then decoding of JPEG, GIF, WEBP.
Change-Id: I19cbb3162acdbfde809df29d49050e3e7cb049db
Bug: skia:9733
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/277598
Reviewed-by: Nathaniel Nifong <nifong@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>
For API simplicity, if the rectangle is to be omitted, the client
should only provide the paint. (emscripten already does parameter
count checking, so let's use that instead of doing it ourselves).
This also adds tests to help verify the new behavior.
Revert "Revert "Allow null rect for saveLayer""
This reverts commit 7957d53c80.
Bug: skia:10043
Change-Id: I9ed8caabbfc77deab1ca3d9b1a415489e012528f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/277399
Reviewed-by: Nathaniel Nifong <nifong@google.com>
Reviewed-by: Dan Field <dnfield@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>
