This effectively reverts reviews.skia.org/122000
Bug: skia:10987
Change-Id: I989241110f17c0e3c2a896aea4bc2bc4cc8c910f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/472801
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This associates the input SkSL source with our debug info. It is
serialized out to .trace files. This will actually let us display the
code associated with `trace_line`.
Bug: skia:12614
Change-Id: I6c10af6fa6dd97ed8411f3460e103f442722b7f6
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/472999
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
The SkVMDebugInfo now includes an skvm::Coord that the caller is
responsible for filling in before converting the program. If it is set,
the value indicates the device coordinates that should be traced. If it
is unset, debug traces will not be emitted at all.
Within the SkVMCodeGenerator, we now have a new traceMask() call which
combines the current execution mask with the trace mask. Tracing opcodes
now pass the result of traceMask() instead of mask(). This will limit
trace data to the selected pixel, instead of tracing the entire draw.
Bug: skia:12614
Change-Id: I1f8ce7d18a31aa60a139a4a7335c2a285d6aee60
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/472798
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
We no longer indicate functions by their line number, which can be
ambiguous. The debug info now includes a list of function names which we
can refer to by index, and the `trace_call` opcode references functions
by their index in this list.
Change-Id: I4bdf2a6439637a07b116831fd2981f342c19ea4a
Bug: skia:12614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/472796
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
We were inconsistent about special treatment for kAlpha_8 vs. other
alpha-only color types (other code paths were already adjusted).
Hopefully, we can remove this special behavior entirely, but as long
as we have this code, let's be somewhat principled.
Change-Id: I373a3c5e8c917d911b55b265631ca964c780a31d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/472996
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This makes behavior (more) consistent with the GPU. In particular, the
alpha_image GM now looks roughly identical (it was very different
before).
Bug: skia:9692
Change-Id: I405375760ffe90577f863fa2d8eb9d2fc0f6edf8
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/472799
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Bug: skia:12633
Change-Id: I3e4542e560a2c876b4b35bf340bdb949c4922c65
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/472556
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
Draws that take a primitive with colors (vertices, patch, atlas) allow
the user to specify how the primitive color is blended with SkShader.
At the public level the blend is specified as SkBlendMode. This change
moves the implementation at SkDevice level over to SkBlender.
Future changes to the existing APIs or future APIs could allow clients
to specify SkBlenders instead of SkBlendMode. THis would would allow for
programmable blending between shader and primitive color.
SkShader_Blend now recognizes if it was constructed with a Mode blender
and extracts the mode enum.
SkBlender_Base::asFragmentProcessor no longer assumes that the dstFP's
input color should be args.fDestColor. Instead the caller
must configure that if desired. (We don't want this for drawAtlas, etc).
Change-Id: I44085da4ec9f4873428f38d629565f7f42c6be91
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/470458
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
This fails exactly as it should, but we had no test for it.
Change-Id: I0aa3307c444f2c9bc3512ff43b784a56a7c09856
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/472449
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This wasn't meaningful, and made some error reporting worse.
Change-Id: I5e72b5aca5d3e159b8439fa9809290d75e44cbe2
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/472656
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Bug: skia:12466
Change-Id: Iafd680901e10d1007a16da0112e41af4bf2f2703
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/472445
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
The `eval` methods take a shader/blender/colorFilter, and we assumed
when assembling the ChildCall expression that the child expression would
be a VariableReference because opaque objects don't participate in
normal expressions. However, comma-expressions were allowed to contain
opaque types. GLSL doesn't allow opaque types in comma-expressions:
http://screen/8YW59tYDUbBh9eW
Now we disallow them as well.
Change-Id: Iaf88ef7bddb5cc8f1f1e23b515174dfc291e00c7
Bug: oss-fuzz:41072
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/472446
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
`void` behaves differently from opaque types in several situations, such
as function return types, and errors involving `void` should not call it
an opaque type. I've fixed all the places where we relied on `isOpaque`
to return catch void types.
Change-Id: I359c00f836be6e56cb0373beff60cf2ff830f77b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/472451
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Mysteriously, I had written a test which put arrays of void inside a
struct, but had neglected to include the non-array case. It causes an
okay-not-great error (referring to void as an "opaque type").
Change-Id: Id20a9d3512d29aecea81d46877dce708b7b2f973
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/472450
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
This reverts commit 12e786730f.
Reason for revert: missing CIPD package on armv6l
Original change's description:
> [python3] More Recipes -> Python 3 fixes
>
> - Set environment variables to force usage of Python 3 in more places
> - Fix more compatibility issues
> - Mark recipes as only supporting Python 3
> - Includes a roll of the infra code
>
> Change-Id: I24e3827a6402c454bdc9467d28864d360632f9e6
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/470303
> Reviewed-by: Ravi Mistry <rmistry@google.com>
> Commit-Queue: Eric Boren <borenet@google.com>
Change-Id: If7b6fcb7838ac053af2c5eb45a7a1ac4aed340a5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/472736
Auto-Submit: Eric Boren <borenet@google.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Change-Id: I209119e6c74ca54dd6021b6dec4775fc7b66adeb
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/472448
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
We should, of course, detect this and report an error.
Change-Id: I42b3be6e714a1f367d3251842506a384f2afe019
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/472447
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Change-Id: I968462c5dd2139b3ff11d8d25efbd5baa3351cba
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/472696
Reviewed-by: Ravi Mistry <rmistry@google.com>
Commit-Queue: Eric Boren <borenet@google.com>
- Set environment variables to force usage of Python 3 in more places
- Fix more compatibility issues
- Mark recipes as only supporting Python 3
- Includes a roll of the infra code
Change-Id: I24e3827a6402c454bdc9467d28864d360632f9e6
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/470303
Reviewed-by: Ravi Mistry <rmistry@google.com>
Commit-Queue: Eric Boren <borenet@google.com>
Importantly, this adds options for encoding using
certain codecs, not just decoding.
Change-Id: I4a610ebf985b67d4545c71b3f3eed4c7807e6a26
Bug: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/472277
Reviewed-by: Ben Wagner <bungeman@google.com>
Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
This re-works src/ports/BUILD.bazel to work like our other
BUILD files, i.e. one rule "srcs" that brings in the necessary
private filegroups.
To work around an abort with LLVM [1], we have to go back to an
earlier version of emscripten (temporarily?).
Future work should look at using transitions [2] to allow various
executables (e.g. CanvasKit, DM) to set their own set of Bazel
flags, w/o the build invokers having to specify them.
These transitions might be able to handle more complex cases
that we currently use if statements in GN to deal with.
The Freetype build rule was created by taking the BUILD.gn
rule, adding in all the sources listed there and then playing
compile-whack-a-mole to add in all the headers and included
.c files.
Suggested Review Order:
- third_party/BUILD.bazel to see freetype build rules
- bazel/common_config_settings/ to see treatment of fontmgr
like codecs (many possible) and fontmgr_factory (only one).
- src/ports/BUILD.bazel
- BUILD.bazel
- modules/canvaskit/BUILD.bazel. Take note of the gen_rule that
calls tools/embed_resources.py to produce the .cpp file
containing the embedded font data.
- Everything else.
[1] https://github.com/emscripten-core/emscripten/issues/15528
[2] https://github.com/bazelbuild/examples/tree/main/rules/starlark_configurations/cc_binary_selectable_copts
Bug: skia:12541
Change-Id: I08dab82a901d80507007b354ca20cbfad2c2388f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/471636
Reviewed-by: Ben Wagner <bungeman@google.com>
Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
This is done for webview which needs to know whether it is drawing
directly into the main window surface or in a layer.
Change-Id: I0a3f6f81bcf65907f9d51651035bae912c3a34ac
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/468616
Commit-Queue: Greg Daniel <egdaniel@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Bug: skia:12466
Change-Id: I6d45f297db4be7e41158d87886ef03905e13eb66
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/472437
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Auto-Submit: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Jim Van Verth <jvanverth@google.com>
This is split out of Michael's CL:
https://skia-review.googlesource.com/c/skia/+/468459
The CommandBufferTest gets a bit shortchanged in this CL but most of those changes should wait until the GraphicsPipelineDesc is expanded anyways.
Bug: skia:12466
Change-Id: Idba20354a4ab158c2bc46f490da23b8f5fcd55b4
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/472336
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
This allows us to dump a trace to disk and read it back in again later.
This uses JSON to ensure a debug trace will stay readable across
platforms, builds, etc.
Change-Id: I4e5011b5023cf14f422ab130e9697c125c2b6e45
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/471765
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Bug: skia:12648
Change-Id: I7fc90be155e6e23696e58a2fcba64e4ae2994b4f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/471436
Commit-Queue: Ravi Mistry <rmistry@google.com>
Reviewed-by: Eric Boren <borenet@google.com>
Previously, we'd report them as an overflowed integer.
Change-Id: Ia3632b4bc880829fb04b08a002d7ce9523567a54
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/472056
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Because SkSL is much more permissive than GLSL about literal types, we
don't actually need to treat values any differently when the `u` suffix
is added. That is, `uint x = 4000000000;` already worked fine. When we
encounter the `u`, we just ignore it. This also means that a literal
like `-100u` would be accepted without complaint (although you'd get a
range error if you tried `uint x = -100u;`).
The value-add here is that it removes a speed bump when porting GLSL
code to SkSL. The Filament example shader used the `u` suffix anywhere
that bitwise ops were present; finding and removing all of them was a
chore.
Also of note: the `u` suffix was only added to GLSL in ES3, but we
"support" it everywhere. (We could go out of our way to detect it in
ES2 and flag an error, but that benefits no one.)
Change-Id: I4bf643612c8cf17710e9bad50a0c16f5936bbe88
Bug: skia:12634
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/471756
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This is required by the ES2 standard: http://screen/Qysv4fPW5r5LA9e
This actually already worked fine because `strtoull` natively recognizes
octal values without any work on our part. However, we lacked a test.
Change-Id: I3033de899918abe99c63a9b7b79bd4c3374ee315
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/471716
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
The CPU blitters use signed 32-bit offsets when gathering source pixels,
so any image larger than that can't be fully indexed. Instead, we'd wrap
around and sample from invalid memory. This does put a new (smaller)
limit on valid image sizes, but it seems unlikely to impact any client.
Bug: chromium:1264705
Change-Id: I21b088c11b49e6410b1f237cbfb6b1639cb22ca0
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/471764
Reviewed-by: Herb Derby <herb@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
