By using npm ci, we can make sure the versions of the helper
libraries (e.g. Karma, Jasmine) we are testing with locally
is the same as the versions we are using in the continuous
integration system.
The copying is needed because our docker recipe forces us
to run as not root, and this was causing some issues. As a
result, I changed the canvaskit test/perf to not re-use the
same file as pathkit does so copying was easier and the
dependencies between the two modules is broken.
Bug: skia:11077
Change-Id: Ib05890d666d3507d4f724a4ae298484629c7932a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/343503
Reviewed-by: Kevin Lubick <kjlubick@google.com>
This is a massive breaking change for all existing users of CanvasKit.
It will be (one of the only) changes in 0.19.0 to make the transition
easier.
Suggested reviewing order:
- index.d.ts (to see type changes). Notice SkPicture still has Sk
prefix, but no other types do (this felt "right" since Sk is
part of the name of the type, but I can be swayed on this).
- canvaskit-wasm-tests.ts
- tests/*.spec.js
- interface.js and helper.js
- html examples
- markdown files
Change-Id: I3b3d3815df2078f986893df3c70101d6248c117d
Docs-Preview: https://skia.org/?cl=322617
Bug: skia:10717
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/322617
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Nathaniel Nifong <nifong@google.com>
CanvasKit.MakeImageFromEncoded, when used with Browser APIs for loading/decoding images.
- `CanvasKit.MakeImageFromCanvasImageSource` takes either an HTMLImageElement,
SVGImageElement, HTMLVideoElement, HTMLCanvasElement, ImageBitmap, or OffscreenCanvas and returns
an SkImage. This function is an alternative to `CanvasKit.MakeImageFromEncoded` for creating
SkImages when loading and decoding images. In the future, codesize of CanvasKit may be able to be
reduced by removing image codecs in wasm, if browser APIs for decoding images are used along with
`CanvasKit.MakeImageFromCanvasImageSource` instead of `CanvasKit.MakeImageFromEncoded`.
- Three usage examples of `CanvasKit.MakeImageFromCanvasImageSource` in core.spec.ts. These
examples use browser APIs to decode images including 2d canvas, bitmaprenderer canvas,
HTMLImageElement and Blob.
- Added support for asynchronous callbacks in perfs and tests.
Here are notes on the image decoding approaches we tested and perfed in the process of finding ways
to use Browser APIs to decode images:
1. pipeline:
ArrayBuffer → ImageData → ctx.putImageData →
context.getImageData → Uint8Array → CanvasKit.MakeImage
❌ Problem: ImageData constructor expects decoded bytes already.
2. interface.js - CanvasKit.ExperimentalCanvas2DMakeImageFromEncoded (async function)
pipeline:
ArrayBuffer → Blob -> HTMLImageElement ->
draw on Canvas2d -> context.getImageData → Uint8Array →
CanvasKit.MakeImage
✅ Works
⏱ Performance: 3rd place (in my testing locally)
3. interface.js - CanvasKit.ExperimentalCanvas2DMakeImageFromEncoded2 (async function)
ArrayBuffer → Blob → ImageBitmap → draw on Canvas2d →
context.getImageData → Uint8Array → CanvasKit.MakeImage
✅ Works
⏱ Performance: 2nd place (in my testing locally)
4. interface.js - CanvasKit.ExperimentalCanvas2DMakeImageFromEncoded3 (async function)
ArrayBuffer → Blob → ImageBitmap →
draw on canvas 1 using bitmaprenderer context →
draw canvas 1 on canvas 2 using drawImage → context2d.getImageData →
Uint8Array → CanvasKit.MakeImage
✅ Works
⏱ Performance: 1st place (in my testing locally) - quite surprising, this in some ways seems to be a more roundabout way of CanvasKit.ExperimentalCanvas2DMakeImageFromEncoded2, but it seems bitmaprenderer context is fairly fast.
Bug: skia:10360
Change-Id: I6fe94b8196dfd1ad0d8929f04bb1697da537ca18
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/295390
Reviewed-by: Kevin Lubick <kjlubick@google.com>
At startup, we allocate a few scratch arrays and then use those
instead of having to malloc and free a bunch of arrays during
runtime.
The benchmark that was added is a bit noisy (probably because
of the garbage collection going on from the created Float32Arrays),
but a few percent faster.
We also don't set the paragraph background/foreground colors to
transparent because we check them being falsey before sending them
over the wire. I noticed that if foreground was transparent black,
no text shows up at all, which was unexpected.
Change-Id: I9f3a590a122d7de222cb5f58ea40e86b2d261c96
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/292685
Reviewed-by: Nathaniel Nifong <nifong@google.com>
This reduces the skm44_concat benchmark from 2us to .35us, a 5x
speedup.
SkCanvas.concat now takes a 3x2, 3x3, or 4x4 matrix and upscales
them all to 4x4. This makes concat44 redundant.
Removes redundant null checks for matrices, since freeing(0)
in WASM is fine like it is in C++.
Change-Id: I44a776ffd0babb81d8a34f9d94ae4d7831d02b55
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/281721
Reviewed-by: Mike Reed <reed@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>
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>
