The problem was we didn't have a way to not build with
SkParagraph, which we can't use when we are using the
primitive shaper.
Change-Id: Iafe070d6f5c01aaa7a42225793d5ad873f144798
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/254968
Reviewed-by: Kevin Lubick <kjlubick@google.com>
We hadn't been requesting one, but told Skia we had one, which caused
issues.
Bug: skia:9564
Change-Id: I9a2e78a528778a386225cdcbbb2d2b3d8f705f05
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/254801
Reviewed-by: Brian Salomon <bsalomon@google.com>
So far Skottie has been assuming all cameras are two-node (have a point
of interest).
AE also supports one-node cameras, where the camera does not auto-orient
towards a POI but starts off perpendicular to the z == 0 plane.
(https://helpx.adobe.com/after-effects/how-to/camera-animation.html)
Change-Id: Id565de7d8feb9a762940ac372c1bbbcce2e2dfc6
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/254559
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Florin Malita <fmalita@chromium.org>
With these things exposed, I think Flutter will not need
CanvasKit to expose the very complex SkCodec API.
Change-Id: Iace1b496d1dcb8842181466e860e8f212aba7b48
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/253542
Reviewed-by: Leon Scroggins <scroggo@google.com>
This happens when validation fails, for example.
Change-Id: Idbd552fbce51c5cf1543fc7a0a34a87230264d6e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/253658
Reviewed-by: Kevin Lubick <kjlubick@google.com>
This reverts commit 1803f4ef6f.
And also fixes the primitive shaper.
Change-Id: Ieaeda5522c98d8a9e6f628b8a6cc30cf41278350
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/252929
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
This reverts commit 0f3a26dd18.
Reason for revert: Windows bots are broken
Original change's description:
> Fix empty run handling in trivial shaper iterators
>
> When the text run is of zero length the iterator starts at the end. The
> trivial itereators did not handle this case.
>
> Change-Id: Id41304500e33d821874f56ab20085cbc4b2d9b0b
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/252857
> Reviewed-by: Herb Derby <herb@google.com>
> Commit-Queue: Ben Wagner <bungeman@google.com>
TBR=bungeman@google.com,herb@google.com
Change-Id: Ia38e46ac4c04def5d374fbbce450538096d90d64
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/252923
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
When the text run is of zero length the iterator starts at the end. The
trivial itereators did not handle this case.
Change-Id: Id41304500e33d821874f56ab20085cbc4b2d9b0b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/252857
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
Refactor as a single interpolating loop, based on careful selection
of lerp coefficients.
Change-Id: I58786cddb2f042b53dcbac80c2346736429be102
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/252858
Commit-Queue: Florin Malita <fmalita@chromium.org>
Reviewed-by: Mike Reed <reed@google.com>
Remove the RGB/YUV helpers (use SkYUVMath instead), along with the
unused get20/set20.
Change-Id: Id83467a1b7f33657869e0a933af75387a4e36a88
Bug: skia:9543
Change-Id: Id83467a1b7f33657869e0a933af75387a4e36a88
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/252188
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Like with the non-relative forms, we want to be able to
chain these together, but not leak the SkPaths (which happens
if the C++ side returns this). Thus, we have to add in
the JS glue to return the "JS this".
Change-Id: Ic640b84f6c09c1d931ad44bc403b14bb0d0893a2
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/251960
Reviewed-by: Hal Canary <halcanary@google.com>
It was easier to just add a few saveLayer overrides rather
than try to expose the struct of pointers. SkRect*
was hard/impossible because we have it as a value_object,
which does not support pointers in enscriptem.
Change-Id: Iad702593cca19f80d6ef9a319f8c80a087135e38
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/250996
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
We are pretty comfy exposing this set for the long-term.
CanvasKit will generally support chains of image filters,
not necessarily arbitrary DAGs, just to simplify the
points needed to expose.
Change the naming around MaskFilters also, I like having
the factories be a class function, just to keep things
a bit better organized and minimize the amount of things
we want to keep on the top level CanvasKit object.
Change-Id: If32c630efa2fd8bc4bac84d0c3461ac3c0d21263
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/250758
Reviewed-by: Robert Phillips <robertphillips@google.com>
Observed AE layer parenting semantics:
* layers are flagged as either 2D or 3D
* camera applies to 3D layers, but not to 2D layers
* parented 3D layers treat their ancestor transform chain as 3D (SkMatrix44)
* parented 2D layers treat their ancestor transform chain as 2D (SkMatrix, ignoring 3D components)
This means that for a given layer, we may need to build two distinct transform chains - depending
on the type of descendant layer being considered.
Furthermore, transforms are animatable and their animators are scoped to a layer controller. Since
we're potentially building two version of the transform node, we need to ensure all animators for
both of them are transferred to controller object (we still want to only instantiate a single layer
controller and render tree to avoid duplication). IOW, all dependent layer transforms need to be
considered before "sealing off" a given layer controller.
In order to avoid a layer dependency/topological sort, we can split off the transform tree
construction into a separate pass. High-level changes:
-- replace existing LayerAttachContext with CompositionBuilder
(holds LayerBuilders and other Composition-wide state)
-- replace LayerRec with LayerBuilder
(holds Layer-wide state and also caches transform nodes)
-- pass 1: for each LayerBuilder, transitively build and cache a transform chain
of a type (2d/3d) determined by the leaf (entry point) layer
-- pass 2: for each LayerBuilder, build the actual layer content render tree
and instantiate the layer controller objects
Bug: skia:8914
Change-Id: I9f7efcf4819424282fd3dda98f5621ba12fd001b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/251001
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Florin Malita <fmalita@chromium.org>
This new freetype lets us have emojis and brings in years
worth of bug fixes from the ancient version shipped in
the emscripten-ports
Change-Id: I0b8779dba3341a3ef73c715fde2e5fb37e45126a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/247296
Reviewed-by: Ben Wagner <bungeman@google.com>
By adding in the check to copy1dArray, some places get the benefit
for free.
Change-Id: I12e230465737dc6276feb02ddb37e3c417777055
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/249878
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Biggest change here is to add initial support for WebGL 2.0 where possible.
Change-Id: I05657dbfeed25fc665205ceda6b35022f6a42053
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/249815
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Add a new seek method which takes a frame index. This provides more accurate
control when rendering of exact frames is needed.
Also surface the animation frame rate, and convert skottie_tool to use this
new mechanism (now defaulting to native animation frame rate).
Change-Id: Id870629e1747a9f70cbf4d3e770366df1299a519
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/249799
Commit-Queue: Florin Malita <fmalita@chromium.org>
Reviewed-by: Mike Klein <mtklein@google.com>
Reviewed-by: Mike Reed <reed@google.com>
When 3D layers are present, we need a camera view even when no explicit
camera is present.
TBR=
Bug: skia:8914
Change-Id: I408986d516e03bc4f80c7c09103e09821704ff2f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/249420
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Florin Malita <fmalita@chromium.org>
Currently, the camera view transform is attached to the render tree as a
TransformEffect. This means it gets "flattened" to an SkMatrix in isolation,
and does not compose with other layer transforms in 4x4 format.
Refactor the implementation to
- build the camera transform upfront
- compose (chain) all layer transforms from this camera transform
This ensures that transform composition happens in SkMatrix44.
E.g. render tree topology change (TE == TransformEffect)
Before:
[root]
|
[TE]<---[CameraT]
|
------------------------------------
| |
| |
[TE]<--[Layer1T] [Layer2T]-->[TE]
| |
[Layer1] [Layer2]
| |
After:
[root]
|
|
------------------------------------
| |
| [CameraT] |
| / \ |
[TE]<--[Layer1T]<-- --->[Layer2T]-->[TE]
| |
[Layer1] [Layer2]
| |
TBR=
Bug: skia:8914
Change-Id: Idd407712f75c48623b5299a4284ddb17b98c155f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/249217
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Florin Malita <fmalita@chromium.org>
- Copy effect state to particle uniforms before each script, so changes
from spawn or update are visible.
- Guard path binding against out of range access
- New effect that actually stresses both of these conditions
Change-Id: Ice6112793099e515438af8bb863e9e1bf03d08b1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/249125
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Gives enough information to locate variables by name (using the same
scheme as glGetUniformLocation), and provide hints about type and size.
Bug: skia:9513
Change-Id: I9444f1042471967a79c9f05167dcdb78eca41bad
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/244502
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Simplify burst handling. Scripts should just add to burst (if
they want to handle programmatic bursting, as well).
Update most effects to handle dynamic updates to position better,
and add a sample effect meant to be used with mouse tracking.
Change-Id: Ia302e1d04e62e2b07974807c44067786cc10a8ad
Bug: skia:9513
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/248798
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Instead of rendering all .mp4 frames then encoding, we can kick off
rendering and have the encoder consume frames in order as they become
available.
This uses std::promise / std::future pairs to make the handoff: frame
producers fulfill thieir promise by moving their image into set_value(),
and the encoder (main thread) consumes them by moving those images out
of the paired std::future(). It may not be obvious, but the line
sk_sp<SkImage> img = frame.get_future().get();
does move the image into `img`... gMP4Frames does not hold a ref once
.get_future().get() has returned. (Though depending on when you look,
the surface still might.)
This lets us get going on encoding as soon as the first frame is ready,
and hypothetically means encoding should finish shortly after the last
frame draws. But, different frames cost different time to draw, and we
can't control the order they'll return. We _do_ have control over the
order they're started, and we're doing that exactly wrong using a LIFO
thread pool. I've added .mp4 encoding starvation stats to show this...
when I run in LIFO order it looks typically something like
starved min 0ms, med 0ms, avg 4.12333ms, max 2115ms, sum 2474ms
frame time min 12ms, med 292ms, avg 307.208ms, max 711ms, sum 184325ms
106.68user 57.27system 0:04.55elapsed 3601%CPU (0avgtext+0avgdata 3159748maxresident)k
0inputs+1528outputs (0major+772790minor)pagefaults 0swaps
Mirroring the batch order with (i = frame_count - 1 - i) results in less
starvation, less memory usage, better scaling, and a quicker wall time.
starved min 0ms, med 0ms, avg 0.896667ms, max 382ms, sum 538ms
frame time min 13ms, med 374ms, avg 344.365ms, max 918ms, sum 206619ms
111.64user 52.56system 0:03.62elapsed 4529%CPU (0avgtext+0avgdata 2660912maxresident)k
0inputs+1528outputs (0major+649031minor)pagefaults 0swaps
Change-Id: Ic60e8eac856af238ef32e3383d86f6c24e5c7851
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/247674
Reviewed-by: Florin Malita <fmalita@chromium.org>
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
