This is the object with the most APIs by far.
Some APIs are stubbed out temporarily and will be given more
detail in a follow-up CL.
Bug: skia:10717
Change-Id: Iff5d4269303e7102ad79de90f20640918f403ff4
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/320770
Reviewed-by: Nathaniel Nifong <nifong@google.com>
I noticed it was broken and untested when writing docs.
Change-Id: I5254b7bd50fde8a361c72ccbd7380809d31ccc08
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/321464
Reviewed-by: Nathaniel Nifong <nifong@google.com>
Note: I intend to make shaping.html live in demos.skia.org, but
that is hard to verify it works until the APIs land.
Change-Id: I3af1cf8ded316f616d05ee60198393ed9c9a284f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/319130
Reviewed-by: Nathaniel Nifong <nifong@google.com>
Reviewed-by: Mike Reed <reed@google.com>
If we have removed any in error, we are happy to add them
back in upon request.
Bug: skia:10717
Change-Id: Ic7be83d6205866e12a9488be83034f15450eb098
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/316842
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Nathaniel Nifong <nifong@google.com>
This allows paint to be used (instead of the less-desirable
drawDrawable impl).
Bug: skia:10717
Change-Id: Id132e7b2bc189303e866f66d90f389bc29c02fb8
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/316840
Reviewed-by: Nathaniel Nifong <nifong@google.com>
I added 3 tests, one using the drawRect API naively,
one using drawRect with a Malloc'd array, and one using
the drawRect4f.
rough local measurements:
- [baseline with tip of tree code]: 50ms
- naive drawRect: 40ms
- drawRect with malloc: 28ms
- drawRect4f: 27ms
I also tried the benchmarks locally with taking in paint
as a const reference. I did not see any changes, but that
could just be small sample size. I plan to land the code
as is for now, collect a bit of data in Perf and then try
landing the const reference stuff and see if we get
something measurable.
To aid this, I added in a helper list of tests to only run
some benchmarks easily.
Change-Id: I2d8c5296e93f05be45fc12059955fb9d9e339d83
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/315143
Reviewed-by: Kevin Lubick <kjlubick@google.com>
This is a reland of bdc214a50e
The CPU version of SkottieWasm is timing out for reasons unknown,
but the GPU version is happy. I think we can get rid of the CPU
version of the job since it has been more or less superseded by
the SkottieFrames one (and the latter is more stable).
Original change's description:
> [canvaskit] Change SkRects to be arrays, not objects.
>
> This changes several APIs, so there are lots of breaking
> notes in the Changelog.
>
> This made the "draw 100 colored regions" benchmark about
> 20% faster (1ms -> .8ms).
>
> In theory, rendering should stay the same.
>
> Change-Id: Ib80b15e2d980ad5d568fff4460d2b529766c1b36
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/312491
> Reviewed-by: Nathaniel Nifong <nifong@google.com>
Change-Id: I674aba85ecfb30b72e94cbaf89b2d97bfae3b7a4
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/315142
Reviewed-by: Nathaniel Nifong <nifong@google.com>
This reverts commit 370de72763.
Reason for revert: Unrelated to breakage
Original change's description:
> Revert "[canvaskit] Replace RRect objects with TypedArrays."
>
> Revert submission 314622
>
> Reason for revert: breaking wasm bots
> Reverted Changes:
> Ia1ba13814:[canvaskit] Replace RRect objects with TypedArrays...
> Ib80b15e2d:[canvaskit] Change SkRects to be arrays, not objec...
> I790b2d6fc:[canvaskit] Add drawRect4f as example 'fast path' ...
>
> Change-Id: I3912ffeb446b497e4e03a6260e51cae1e664bd83
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/314894
> Reviewed-by: Michael Ludwig <michaelludwig@google.com>
TBR=kjlubick@google.com,michaelludwig@google.com,nifong@google.com
# Not skipping CQ checks because this is a reland.
Change-Id: I9b1e38fd36f635146b3b518142bbc4626007700f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/315141
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Revert submission 314622
Reason for revert: breaking wasm bots
Reverted Changes:
Ia1ba13814:[canvaskit] Replace RRect objects with TypedArrays...
Ib80b15e2d:[canvaskit] Change SkRects to be arrays, not objec...
I790b2d6fc:[canvaskit] Add drawRect4f as example 'fast path' ...
Change-Id: I3912ffeb446b497e4e03a6260e51cae1e664bd83
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/314894
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Revert submission 314622
Reason for revert: breaking wasm bots
Reverted Changes:
Ia1ba13814:[canvaskit] Replace RRect objects with TypedArrays...
Ib80b15e2d:[canvaskit] Change SkRects to be arrays, not objec...
I790b2d6fc:[canvaskit] Add drawRect4f as example 'fast path' ...
Change-Id: Ie6e4c57ba412ca9ff8e4446b06681b51029da2d6
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/314893
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Revert submission 314622
Reason for revert: breaking wasm bots
Reverted Changes:
Ia1ba13814:[canvaskit] Replace RRect objects with TypedArrays...
Ib80b15e2d:[canvaskit] Change SkRects to be arrays, not objec...
I790b2d6fc:[canvaskit] Add drawRect4f as example 'fast path' ...
Change-Id: I295791532a2d27bff41f706fa8ed37e0499c27d7
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/314892
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
I added 3 tests, one using the drawRect API naively,
one using drawRect with a Malloc'd array, and one using
the drawRect4f.
rough local measurements:
- [baseline with tip of tree code]: 50ms
- naive drawRect: 40ms
- drawRect with malloc: 28ms
- drawRect4f: 27ms
I also tried the benchmarks locally with taking in paint
as a const reference. I did not see any changes, but that
could just be small sample size. I plan to land the code
as is for now, collect a bit of data in Perf and then try
landing the const reference stuff and see if we get
something measurable.
To aid this, I added in a helper list of tests to only run
some benchmarks easily.
Change-Id: I790b2d6fc32c125a4d371768fffb19ab22633d4e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/314622
Reviewed-by: Kevin Lubick <kjlubick@google.com>
This changes several APIs, so there are lots of breaking
notes in the Changelog.
This made the "draw 100 colored regions" benchmark about
20% faster (1ms -> .8ms).
In theory, rendering should stay the same.
Change-Id: Ib80b15e2d980ad5d568fff4460d2b529766c1b36
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/312491
Reviewed-by: Nathaniel Nifong <nifong@google.com>
This is about 2.5x faster.
Will try to do the same for Rects in a followup CL.
Change-Id: Ia1ba1381435f4eee2fcf4f0cc2738e3306edd5f9
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/312304
Reviewed-by: Nathaniel Nifong <nifong@google.com>
There is no more 'inout half4 color'. Effects return their output color.
If an effect wants the input color, it must use the (already existing)
approach of sampling a nullptr input shader.
The change is guarded for Chromium (so we can update their runtime color
filters in skia_renderer.cc).
For the GPU backend, FPs can now override usesExplicitReturn to indicate
that their emitCode will generate a return statement. If that's true,
then writeProcessorFunction doesn't inject the automatic return of the
output color, and emitFragProc will *always* wrap that FP in a helper
function, even as a top-level FP. GrSkSLFP opts in to this behavior, so
that the user-supplied return becomes the actual return in the FP's
emitCode.
Adapting the skvm code to this wasn't too bad: It looks fragile (what
happens if there are multiple returns?), but that's not really possible
today, without varying control flow.
Bug: skia:10613
Change-Id: I205b81fd87dd32bab30b6d6d5fc78853485da036
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/310756
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
This saves about 15kb of wasm code size (4kb gzipped), 11kb
of JS code size (2kb gzipped) and about 10ms
when creating a new surface (~35ms -> 25ms in a local test).
This also gates the webgl code more strongly (off unless you
really request it), since the headers won't be available
except in an emscripten environment.
Change-Id: I303f6c342c72e7cfe29be241f55ae8f5631a3f75
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/311916
Reviewed-by: Brian Salomon <bsalomon@google.com>
There was a break that was solved by adding -lGL to our link
steps. I discovered a few extra flags to aid in debugging builds
and I've left those in (they aren't too noisy IMO).
This changes the base dockerfile to use the official emscripten one.
Code size delta for full build is +5 kb
For future reference, emsdk decides which "library JS" files to
pull in using a83ba99d60/tools/building.py (L1553)
Those JS files live in src (e.g. a83ba99d60/src/library_html5_webgl.js (L222))
and define functions that the C++ code can call.
I'd like to follow-up on what -lEGL is doing.
Also, since the new image no longer has depot_tools, we need
to make docker/skia-wasm-release/Dockerfile install it.
Change-Id: I5a38e61e5080e9c4cb1e0a7e031509bcb107ff86
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/311726
Reviewed-by: Nathaniel Nifong <nifong@google.com>
Previously one could not color text with paints, even though TextStyle's foregroundColor and
backgroundColor fields are SkPaints. Canvaskit only exposed these as colors in order to allow
SimpleTextStyle to be a value object that would not have to be deleted by the user.
CanvasKit.Paint is a bound SkPaint. I wanted to allow a user to pass a paint to be used
in a text style without alterting SimpleTextStyle's status as a value-object.
So I've added a new bound method, pushPaintStyle which acts just like pushStyle but allows
a foreground and background paint to be supplied which are used to override the existing paints.
The user is responsible for deleting these paints.
Sorry for the kludgy design, if you have got a more elegant way, I'm open to suggestions.
Change-Id: Ib78464171346fe9f717f6d5b9d9428b1d0278498
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/307596
Commit-Queue: Nathaniel Nifong <nifong@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Julia Lavrova <jlavrova@google.com>
Change-Id: Ie55e876638246a444c32b169ed3830cd7b0fbab3
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/304861
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
These changes were supposed to land yesterday, but I forgot.
Change-Id: I46aca428482f9812c1b025f9735ebe2c0ac02bf1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/304602
Reviewed-by: Kevin Lubick <kjlubick@google.com>
This also makes the effects deserialization available via compile flag.
Change-Id: Ib6692499a619205ac480a8823ce7de12c0a5a723
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/303596
Reviewed-by: Nathaniel Nifong <nifong@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>
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>
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>
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>
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
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>
breaks CPU-backed canvaskit build
This reverts commit 3d52abc846.
Reason for revert: <INSERT REASONING HERE>
Original change's description:
> Wide color gamut support and working example.
>
> 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.
>
> Change-Id: I3dea5b16c60a3871cd2a54f86716f4a438a90135
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/289733
> Commit-Queue: Nathaniel Nifong <nifong@google.com>
> Reviewed-by: Kevin Lubick <kjlubick@google.com>
TBR=kjlubick@google.com,brianosman@google.com,nifong@google.com
Change-Id: I2e03155c2512eec6730ecccda19df78174146008
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/291339
Reviewed-by: Nathaniel Nifong <nifong@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Commit-Queue: Nathaniel Nifong <nifong@google.com>
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.
Change-Id: I3dea5b16c60a3871cd2a54f86716f4a438a90135
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/289733
Commit-Queue: Nathaniel Nifong <nifong@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Changes are largely mechanical. Non-mechanical changes to support newer
versions of emscripten are enumerated below, in format ${EMSCRIPTEN_VERSION}:
${RELEVANT_CHANGE}.
- 1.39.9: TOTAL_MEMORY has been renamed INITIAL_MEMORY.
- 1.39.12: passing of linker flags to wasm-ld has changed in a way that requires
supplying `--no-entry` to avoid error message "wasm-ld: error: entry symbol
not defined (pass --no-entry to suppress): main".
- 1.39.16: The factory function created by using `MODULARIZE` build option now
returns a Promise instead of the module instance. As such, the ready.js
workaround is removed. Note this is a breaking API change for CanvasKit,
which now uses just `then()` and not `ready().then()`.
- 1.38.33: `emsdk install` hasn't required the `-64bit` suffix on version names
since `1.38.33`, so we remove them. E.g. `emsdk install sdk-1.39.6-64bit`
simply becomes `emsdk install sdk-1.39.16`.
cf. https://github.com/emscripten-core/emscripten/blob/master/ChangeLog.md
Bug: NONE
Change-Id: Iabec4bd5ad7db2e0715ad42c2e4cf7d67b192b4c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/291182
Reviewed-by: Kevin Lubick <kjlubick@google.com>
