To make the atomic rules a bit easier to work with, in many
of the folders, this adds in cc_library rules to group
together the sources from that folder (and subfolders
where prudent). We only needs sources because those atoms
should have their headers as deps.
One issue that was pointed out is that there is currently
no way to restrict the inclusion of certain packages,
a la, `gn check`. For example, there is no mechanism from
stopping a dev from adding
#include "modules/canvaskit/WasmCommon.h"
to something in //src/core (except circular dependencies).
We can probably address that using Bazel's visibility
rules as needed:
https://docs.bazel.build/versions/main/visibility.htmlhttps://docs.bazel.build/versions/main/be/functions.html#package_group
It is recommended to look at this CL patchset by patchset.
PS1: Update gazelle command to generate rules in more folders.
PS2: A few changes to make generation work better.
PS3: The result of running make generate in //bazel
PS4: Adding the rules to build sksllex, the simplest binary I
could find in the Skia repo.
PS5: Adding the rules to build skdiff, a more complex binary.
I tried a few approaches, but ended up gravitating back
towards the layout where we have each folder/package
group up the sources. I imagine at some point, we'll have
skdiff depend on skia_core or something, which will
have things like //src/core, //src/codecs, //src/pathops
all bundled together.
PS7: Added in the groupings of sources, similar to what we had
earlier. I liked these for readability. These helped fix
up the //:skia_core build, and by extension, the CanvasKit
build.
Change-Id: I3faa7c4e821c876b243617aacf0246efa524cbde
Bug: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/476219
Reviewed-by: Ben Wagner <bungeman@google.com>
Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
1) CachingResourceProvider - The immediate user of this is ChromeOS,
but it seems like a generally useful ResourceProvider implementation
that all can use.
2) Animation::Builder - See this CL:
https://chromium-review.googlesource.com/c/chromium/src/+/3171517
It seems that windows builds fail with "undefined reference" linker
errors when trying to use the Animation::Builder directly. My guess
is that this is because the SK_API macro is needed to export it.
Change-Id: Ief39fe6ec03f992a0be73e5be54b0119d2d82930
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/458407
Commit-Queue: Florin Malita <fmalita@google.com>
Reviewed-by: Florin Malita <fmalita@google.com>
ResourceProviderProxyBase is supposed to forward all virtuals to fProxy,
but it currently drops loadAudioAsset().
TBR=
Change-Id: I8c690802cd3ba6078232e210b032aa67499d7ba8
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/368116
Auto-Submit: Florin Malita <fmalita@chromium.org>
Reviewed-by: Florin Malita <fmalita@google.com>
Commit-Queue: Florin Malita <fmalita@google.com>
Commit-Queue: Florin Malita <fmalita@chromium.org>
Expand the SkImageAsset API to support controlling sampling options and
pass an additional transform.
Bug: skia:10944, skia:10942
Change-Id: I7bad0b2ab58ed40fe4b425de0eb6970a4c7d7117
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/340097
Commit-Queue: Florin Malita <fmalita@chromium.org>
Commit-Queue: Florin Malita <fmalita@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Looking at audio layer support for Skottie, we need an API to
externalize audio asset loading and playback.
Similar approach to the other resource types for loading, but in
addition we also delegate playback control to the embedder.
First thought: keep it really simple and just emit seek() events.
Positive |t|s for track playback, negative for track off.
The embedder needs to implement state menagement (playing/not-playing)
and optional synchronization (if animation playback is not real time).
Change-Id: I54d1c2c39d0c38dd926f7c93764bde6695cb3fe2
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/309317
Commit-Queue: Florin Malita <fmalita@google.com>
Reviewed-by: Mike Reed <reed@google.com>
The MultiFrameImageAsset helper can be flagged to decode lazy images
upfront (to avoid run-time decoding and resource cache interactions).
But when pre-decoding is enabled, MultiFrameImageAsset yields a
different SkImage for every request - *even for static images*.
This means that e.g. each image layer precomp instance gets its own
copy of the data. Bad bad bad.
Update MultiFrameImageAsset to cache the last frame, and reuse when
backed by a static image.
Change-Id: I65431e7ccf4a64f0055f935f9823c33402d1bb2b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/306938
Commit-Queue: Florin Malita <fmalita@google.com>
Reviewed-by: Mike Reed <reed@google.com>
BM can now export inline fonts, encoded as data-uris.
Extend our DataURIResourceProviderProxy helper to also intercept and
decode inline typefaces.
Change-Id: Iaf1be9db2fd32383af78bc351b1228fe6b3b64bf
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/305685
Commit-Queue: Florin Malita <fmalita@chromium.org>
Commit-Queue: Ben Wagner <bungeman@google.com>
Auto-Submit: Florin Malita <fmalita@chromium.org>
Reviewed-by: Ben Wagner <bungeman@google.com>
Although deprecated, loadFont is still in use - we should proxy it for
now.
Change-Id: Iccef76d4ba394d08fc61c7471def8dee470db695
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/305516
Auto-Submit: Florin Malita <fmalita@chromium.org>
Commit-Queue: Florin Malita <fmalita@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
Some clients already have SkTypeface objects, and forcing them to pass
these as SkData is awkward - especially since Skottie immediately turns
them into SkTypeface again.
Replace the existing loadFont() callback with loadTypeface().
(for compatibility, we try both for now, but the plan is to phase-out
loadFont)
Change-Id: Ib4c2446a96cb6a5f95581c405d0a1b4ecff7ddb2
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/296718
Reviewed-by: Mike Reed <reed@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Florin Malita <fmalita@google.com>
For now, we'll have two copies. Once clients are using the skresources
versions exclusively, we can remove the originals from skottie.
Change-Id: I3152f526b0505b8374bdd9b4513a80bddc702ccc
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/256416
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
This is a first pass that should help with migrating clients.
The utility implementations of ResourceProvider are still in
skottie - those are going to be harder to move. More likely
that I'll add parallel implementations in skresources, then
we can shift clients over and delete the skottie copy.
I'm planning to use this interface/system in particles.
Bug: skia:9513
Change-Id: I004da685983c05cb1b48a75f8a23bd7d73a3f5af
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/256077
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
