This reverts commit 73923522fd.
Reason for revert: breaks Perf-Debian10-EMCC-GCE-CPU-AVX2-wasm-Release-All-Puppeteer_RenderSKP perhaps?
Original change's description:
> Enable effects deserialization except for npm build
>
> Enable skia picture effect deserialization in all flavours of build
> except for "npm" variant. If you don't have effect deserialzation enabled
> then when you try to deserialize a skp into SkPicture using canavskit
> it will simply ignore all the shaders/ effects.
>
> On npm build effects are still being dropped if you use skia picture
> this is being done intentially to not increase the size of canvaskit wasm and
> js files.
>
> https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!searchin/skia-discuss/gradient$20canvaskit%7Csort:date/skia-discuss/hiCxK-VkK4o/i9zO-tm7AQAJ
>
> Change-Id: Iff27f829cd72d23cafaddeade5c37de412f9ce19
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/301676
> Reviewed-by: Kevin Lubick <kjlubick@google.com>
TBR=kjlubick@google.com,sunilmur@amazon.com
Change-Id: Ic14bcdbe16761971d685fc088666d02af99b31fa
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/302021
Reviewed-by: Kevin Lubick <kjlubick@google.com>
The `experimental_simd` build target builds
CanvasKit using the Emscripten `-msimd128` flag, to build CanvasKit
with SIMD instructions in the compiled WASM. This build of
CanvasKit works in Chrome Canary 86.0.4186.0
with chrome://flags#enable-webassembly-simd enabled.
Also add WebAssembly-specific intrinsics to SkVx.h to enable
support for almost all native SIMD operations in CanvasKit WebAssmebly.
Also add a Skia/modules/canvaskit/wasm_tools/SIMD folder which contains
build_simd_test.sh for testing whether WASM SIMD intrinsics operations
are actually being used by skvx, and for testing correctness of
WASM SIMD operations. Also contains simd_float_test.cpp and
simd_int_test.cpp which serve as documentation for which operations are
correctly turned into WASM SIMD operations by emscripten.
Bug: skia:10453
Change-Id: Icd312b4d189e8d8667d3ffe12a72bfa6febaab2f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/299705
Reviewed-by: Mike Klein <mtklein@google.com>
https://skia-review.googlesource.com/c/skia/+/297896 draws
several paths with over 1000 points (one has ~250k) and
was pretty slow. We already had a way to provide a flat(ish)
array of all the verbs, points and weights mushed together
(although that should be cleaned up to prefer taking a 1d
array).
This adds an additional way to provide multiple verbs,
points, (and optionally weights, if conics are used) to CanvasKit.
This makes things dramatically faster because of batch copying
the values between JS and WASM (or using Malloc).
Additionally, the above CL revealed a need to be able to
use a subsection of a Malloc'd array efficiently. Thus,
I added subarray as a method of the Malloc object, which
can be used effectively as a pointer (i.e. no copying).
Change-Id: I2c1d26b25118fb9949e878b1b519d93efcfa5019
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/297841
Reviewed-by: Nathaniel Nifong <nifong@google.com>
Reviewed-by: Chris Dalton <csmartdalton@google.com>
This allows users to create their context with {antialias: true} and
*hope* for MSAA. This CL also updates viewer.html achieve MSAA with this
method, and if the browser doesn't give an MSAA, we simply abort.
Change-Id: Ia242d266123c4b08f15a357e1fedc449642d88d3
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/297597
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Commit-Queue: Chris Dalton <csmartdalton@google.com>
proposed and upcoming APIs and how they may be able to be used with
CanvasKit.
Change-Id: I085e65e7e3c58ef2cbe2ce60ddd813b2c531c890
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/296752
Reviewed-by: Kevin Lubick <kjlubick@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>
This updates an existing test and adds a new one to make
sure we don't regress.
Change-Id: If94eb3fb205852750d6fb9483e20c07d88b4da10
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/295560
Reviewed-by: Nathaniel Nifong <nifong@google.com>
TODO:
1. Accept a Color builder or a TypeArray from CanvasKit.Malloc
2. Apply the same treatment to all other gradient functions, MakeSkVertices, and drawAtlas
Change-Id: I94fa67a3c00d7b1ecdc004af4ffd3193404c1a30
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/294707
Commit-Queue: Nathaniel Nifong <nifong@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Change-Id: Id7c51504450c1c7c9421eba3838bd6bc3440ca4f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/295437
Reviewed-by: Mike Klein <mtklein@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
Its effect is small and we want to rely on SkReadBuffer being available.
Size changes:
- canvaskit uncompressed: 6,864,481 --> 6,864,481 ( no change )
- canvaskit compressed: 2,667,117 --> 2,667,117 ( no change )
- pathkit uncompressed: 329,187 --> 330,679 (+ 1.5K, +0.5%)
- pathkit compressed: 134,158 --> 134,672 (+ 0.5K, +0.4%)
- flutter : 1,302,108 --> 1,322,568 (+20.0K, +1.6%)
The Flutter change is the biggest mystery, as bloaty only pegs
SkReadBuffer as 3.9K. The rest must come from other files including
SkReadBuffer.h not being able to see and inline away SkReadBuffer
routines? Feels like SK_DISABLE_EFFECT_DESERIALIZATION isn't trimming
enough?
PS 4-6 have an idea to push SK_DISABLE_EFFECT_DESERIALIZATION further.
Change-Id: Ifda3ccb82dd0636cfed6bb826fb185a7bca2cbe0
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/295061
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
The bug here is very subtle, as is the mitigation.
Quick background on WASM memory, there is an object
called wasmMemory (which might be hoisted into scope for
CanvasKit's pre-js functions), of type WebAssembly.Memory
which is a resizable ArrayBuffer. Emscripten provides the
JS code to initialize this and handle size increases.
Emscripten also provides TypedArray "views" into this buffer.
These are called CanvasKit.HEAPU8, CanvasKit.HEAPF32, etc.
When there is a call to CanvasKit._malloc, wasmMemory may
be resized. If that happens, the previous TypedArray views
become invalid. However, in the same call to _malloc,
emscripten will refresh the views [1]. So, dealing with
CanvasKit.HEAPU8 directly (quick aside, we never expect clients
to mess with these views, only us in our glue JS code
[e.g. interface.js]), should always be safe because if they
were to be invalidated in a call to _malloc, the views would
be refreshed before _malloc continues.
The problem that existed before was when we were passing
CanvasKit.HEAP* as a parameter to a function, in which the
function would call _malloc before using the typed array
parameter:
//... let us suppose wasmMemory is backed by ArrayBuffer D
copy1dArray(arr, HEAPU32);
// The HEAPU32 TypedArray (backed by ArrayBuffer D) is stored
// to a function parameter "dest"
function copy1dArray(arr, dest, ptr) {
// ...
if (!ptr) {
ptr = CanvasKit._malloc(arr.length * dest.BYTES_PER_ELEMENT);
// Suppose _malloc needs to resize wasmMemory and is
// now backed by ArrayBuffer E.
// Note: The field CanvasKit.HEAPU32 is correctly backed
// by ArrayBuffer E, but variable dest still points to a
// TypedArray backed by ArrayBuffer D.
}
// dest.set will fail with a "neutered ArrayBuffer" error
// because ArrayBuffer D is effectively gone (replaced by E).
dest.set(arr, ptr / dest.BYTES_PER_ELEMENT);
The fix here is to pass in the field name indicating the TypedArray
view we want to write our data into instead of using the
view itself as the parameter.
[1] e427159553/src/preamble.js (L344)
Change-Id: I46cfb98f8bdf928b61690a5ced034a5961356398
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/294516
Reviewed-by: Nathaniel Nifong <nifong@google.com>
Also confirm that Flutter Web and Canvas represent colors
as ints in the same way.
Change-Id: Ie8c2f9a48542510063c9bbc408a8047e0cc3969f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/293840
Reviewed-by: Kevin Lubick <kjlubick@google.com>
CanvasKit converts 4 floats to an int, just to have it be
converted back into 4 floats when it goes into the paint.
Change-Id: I93cf1c596283b83cc9452fb205b7000ceed09bb9
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/293538
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Mike Reed <reed@google.com>
There's some flakes on the _dommatrix test. This adds an extra assertion
to maybe shed some light on that flake.
Change-Id: I548d3294c8f3c620a9702e4d4889da745a2d91fe
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/293764
Reviewed-by: Kevin Lubick <kjlubick@google.com>
We force animation in order to measure fps.
HINT: Launch chrome with --disable-frame-rate-limit and
--disable-gpu-vsync in order to measure frame rates above 60.
Change-Id: I08fae8fc2eb65930f81110999a64eed9df9c704f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/292994
Commit-Queue: Chris Dalton <csmartdalton@google.com>
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>
Surface clients can now specify a dirty rect that will constrain HTML canvas
repaints to a particular region.
Bug: NONE
Change-Id: Ia77d6e864c061297bfc82cfa09030523052ee0e1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/293056
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Fix a bug with paragraph text direction that an incorrect unit test wasn't detecting.
Change-Id: I73418ea8a90da097078d93ddf8692a55488f672f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/292366
Commit-Queue: Nathaniel Nifong <nifong@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Also enables ccpr and makes flags parsing more robust.
Change-Id: Ia98467403de87423a63167681b2ee635b0fa593a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/292690
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
If ever CanvasKit accepts an array as a parameter, if the array
provided was produced by Malloc, CanvasKit will use the pointer
of that array and not free it after.
Change-Id: I4806a48e5e030edd787944f652984ea3516b3022
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/292561
Reviewed-by: Nathaniel Nifong <nifong@google.com>
The new loader works by checking for a "slide" flag, and if it ends in
".skp", then we treat the slide name as a URL and try to pull it in with
an HTTP request and parse it as an SkPicture.
It is the user's responsibility to copy or link skps into their
canvaskit server directory.
Change-Id: Iaafa84300d36d2d5a0bb29c47761ec67076c0f50
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/292204
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Adds a simple system for the user to supply flags via the location hash.
e.g., "http://.../viewer.html#msaa:8"
Implements the msaa flag by rendering to a multisampled offscreen
framebuffer, then blitting it to the main canvas framebuffer.
Change-Id: I7f2b8b769e491f2169fd6b967a72a8ea9c8ffb8b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/292199
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Consider rendering an SkPicture to a 1080p, 4x msaa render target:
1920 * 1080 * (4 color bytes + 1 stencil byte) * 4 samples = 40Mb!
But SkCanvas::drawPicture calls saveLayer, which allocates a duplicate
render target:
40Mb * 2 = 80Mb!!
So with the original 96MB, a quite conservative msaa render target
almost blows out the entire resource cache just on the backing. This
CL bumps up the default cache size to 256MB.
Change-Id: I756c62f4ee6b9c62b1a3e535f31e15a1ecc3d63f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/292265
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Fixes release-cpu build issue, un-revert cl 289733
Color space arguments accepted at surface creation, paint, gradient, and other call sites.
Works correctly only when chrome happens to be rendering itself in the same color space
the canvaskit user has chosen, there's not yet end to end color management of
canvases supported in browsers.
readPixels not yet working due to possible chrome bug.
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/289733
Commit-Queue: Nathaniel Nifong <nifong@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Change-Id: I65ce1c643dac57e14b8476f598c96b12b7e040ce
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/291896
One immediate use-case for this is running tests when SSH'd into a
remote machine. In theory, X11 forwarding could be used to forward the
remote Chrome UI. In practice, Chrome is difficult to forward
correctly, and the options for doing so are empirically quite slow. In
testing, forwarding from Ubuntu to Mac required passing
--use-gl=swiftshader to Chromium, and rendering was slow enough to
timeout tests.
Bug: NONE
Change-Id: Ibfaa406a73d293ea212d7983d487ea0de9722da5
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/291196
Reviewed-by: Kevin Lubick <kjlubick@google.com>
We were accidentally turning on MSAA via the "antialias" context attrib,
then feeding the render target into Ganesh and saying it was non-MSAA.
This will cause rendering artifacts in Ganesh if MSAA is unknowingly
enabled when we try to do coverage-based AA.
Also, the WebGL spec does not give us control over the exact sample
count or even guarantee that "antialias" means MSAA, so I think it's
best to leave that flag disabled by default. If a client wants MSAA,
they can create their own offscreen surface and blit it into the main
canvas.
Change-Id: I45f1596bfe9258963cff4b5d0a3921c5ba43145f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/291029
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
