Kaylee Lubick

Fix SkPathBuilder::snapshot() with non-affine matrices The fuzzer noticed some asserts that were triggered as a result of us preserving the isA part when we shouldn't have (e.g. perspective transforms). This fixes that behavior. Bug: oss-fuzz:511659804 Fixed: 511659804 Change-Id: Ifa9250000a458037dbd170163da5c2b125fe7b20 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/1310197 Reviewed-by: Florin Malita <fmalita@google.com> Commit-Queue: Florin Malita <fmalita@google.com> Auto-Submit: Kaylee Lubick <kjlubick@google.com>

Address incorrect handling of a map pointer in SkRP In pushChildCall, we held on to a pointer from a fChildEffectMap and then later dereferenced it. However, in between those points was a code path that could grow the map, invalidating the pointer. This is demonstrated in the newly added test. To fix it, we just dereference it earlier. While tracking this down, I found a suspicious other usage of the map which works in newer C++, but could break in older versions. It's trivial to fix Generator::writeFunction, so I handled that as well. Bug: b/540157141 Fixed: 540157141 Change-Id: I149b070c31d4cfefa65b30972f0b8b94441e66db Reviewed-on: https://skia-review.googlesource.com/c/skia/+/1308776 Reviewed-by: Jorge Betancourt <jmbetancourt@google.com> Commit-Queue: Kaylee Lubick <kjlubick@google.com>

Add sanitization proc to SkTypeface::MakeDeserialize If someone wants to validate or rewrite (OTS-style) the bytes in the stream before they are passed to Fontations etc, they need a hook like this one to achieve that. Otherwise, they'd need to be able to work around Skia's stream format which includes metadata that we'd like others to not depend on. See also https://crrev.com/c/8126755 Change-Id: I765770dba32f60a76d93b75670529f30fc236bb9 Bug: b/497603247 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/1297116 Commit-Queue: Kaylee Lubick <kjlubick@google.com> Reviewed-by: Florin Malita <fmalita@google.com>

Avoid timeout in SkRegion::setPath This path attempted to draw 11 billion tiles which seems excessive. I calculate how many tiles are needed and stop if it's above 1000 (chosen somewhat arbitrarily). Change-Id: Ied3794b48c2dbe56ba566eae0a99f22ef6ccc3f9 Bug: oss-fuzz:510359475 Fixed: 510359475 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/1310356 Commit-Queue: Kaylee Lubick <kjlubick@google.com> Commit-Queue: Alexis Cruz-Ayala <alexisdavidc@google.com> Auto-Submit: Kaylee Lubick <kjlubick@google.com> Reviewed-by: Alexis Cruz-Ayala <alexisdavidc@google.com>

[bazel] Add support to viewer for Windows (and all Direct3D backends) bazel run //tools/viewer runs on my local windows machine with Graphite+Dawn+D3D11 and D3D12 as well as the Ganesh + D3D backend. Suggested review order: - tools/viewer/BUILD.bazel (Freetype is going to take some fiddling to get to work but we prefer to test with SkFontMgr_New_GDI anyway. - tools/window/BUILD.bazel and tools/sk_app/... (these mirror the Linux and Mac versions pretty closely) - All other BUILD.bazel files - All .cpp files (note that src/gpu/ganesh/d3d/GrD3DBackendSurface.cpp had quietly been broken during the modularization and we didn't notice it until doing a modular build). - All other files Bug: 256860862 Bug: 256870320 Change-Id: I8671a6b2c11a5b2b8703cdc44b9bbeae9fb12e7a Reviewed-on: https://skia-review.googlesource.com/c/skia/+/1293798 Reviewed-by: Eric Boren <borenet@google.com>

[bazel] Add Windows CI job for building viewer This proves we can run Bazel on our Windows machines. There ended up being a few pieces that were tricky due to the fact the VMs don't have a Windows toolchain (or Python) installed on them. Suggested review order: 1) gen_tasks_logic.go to see that all Bazel tasks need Python (I guess Mac and Linux already had one) because dawn_repo.bzl uses Python to generate the dawn_files.bzl and we can't use the hermetic Python because it isn't ready when the repo rules are running. See also dawn_repo.bzl for additional comments about that. We also need the win_toolchain because bazel.exe (downloaded by bazelisk.exe) is dynamically linked, not statically linked. 2) windows_toolchain_config.bzl to see some of the changes needed to get the rust toolchain working when there isn't a toolchain available. Short answer: static linking. 3) bazel_build.go to see how we pipe through the windows toolchain into PATH and BAZEL_VC for both top level Bazel commands to use and the lower level rules_rust commands. Marvel at the annoyance of Path vs PATH (I hope they fixed this in later versions of Bazel or rules_rust). 4) jobs.json and tasks.json are mechanical. For future reference [1] is how to get the dll deps from a Windows exe (which helped me identify the missing dlls since the "error status 0xc0000135" is all I got). [1] http://gpaste/4507126927065088 Bug: b/532498677 Change-Id: I0857d5e14ffde23a17b559acdf3711b43350b0ee Reviewed-on: https://skia-review.googlesource.com/c/skia/+/1294676 Commit-Queue: Kaylee Lubick <kjlubick@google.com> Reviewed-by: Eric Boren <borenet@google.com> Reviewed-by: Jorge Betancourt <jmbetancourt@google.com>

Update viewer help flags I noticed the flags (e.g. dawn) for --backend's help message were out of date. The intent was to update this dynamically based on what was compiled in, but this bitrotted. I updated this to match the logic for get_backend_type Change-Id: Ic6d3565b8f644ca87f4fb742b78d264d1a0c8079 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/1313016 Commit-Queue: Kaylee Lubick <kjlubick@google.com> Auto-Submit: Kaylee Lubick <kjlubick@google.com> Commit-Queue: Alexis Cruz-Ayala <alexisdavidc@google.com> Reviewed-by: Alexis Cruz-Ayala <alexisdavidc@google.com>

Clarify comments in SkEdge While dealing with a bug in this code, I came back to some comments I left unfinished and filled out the explanations a bit. Change-Id: I6ef6cc29a8c3cdee61bec919e12605d1626a96a2 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/1283276 Commit-Queue: Alexis Cruz-Ayala <alexisdavidc@google.com> Reviewed-by: Alexis Cruz-Ayala <alexisdavidc@google.com>

Avoid integer overflow in SkRasterPipeline I wasn't able to get this to repro like https://review.skia.org/1253418 (by adding a case in resources/sksl) but I was by adding a manual test. Not quite sure why. Bug: oss-fuzz:416061512 Change-Id: I61275c5c1372c2d49d37a05dcdde32a72dadc0d5 Fixed: 416061512 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/1311496 Reviewed-by: Jorge Betancourt <jmbetancourt@google.com> Auto-Submit: Kaylee Lubick <kjlubick@google.com> Commit-Queue: Jorge Betancourt <jmbetancourt@google.com>

Add Bazel task to build on Intel Macs This makes sure our toolchain works on hosts which are older Macs. Previous mac builds had accidentally been working because they'd run on machines which had previously run with recipes that used the "install xcode" [1] step. This means when we start running task drivers on Macs that only use the task driver (e.g. the Intel macs I targeted for this new task), it would fail with: Error in fail: Error Getting SDK path: xcode-select: note: No developer tools were found, requesting install. If developer tools are located at a non-default location on disk, use `sudo xcode-select --switch path/to/Xcode.app` to specify the Xcode that you wish to use for command line developer tools, and cancel the installation dialog. This ports that command to our mac task drivers. Unlike the task drivers, we don't use sudo to switch to the xcode, instead we use DEVELOPER_DIR to achieve that. I chose the MacBookPro15.1 machines (cpu:x86-64-i9-8950HK) because we have the most of those. We have those on Mac 14 and 15 and I don't really care which of those we run on (we are just compiling), so I didn't specify. [1] https://github.com/google/skia/blob/2c4e3993fd1c68ee7f1561a0fca782623ec6f1b0/infra/bots/recipe_modules/xcode/api.py#L56 Change-Id: I97bccf88498814554600ef0eb978a47ed8729971 Bug: 256863909 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/1288656 Reviewed-by: Eric Boren <borenet@google.com> Commit-Queue: Kaylee Lubick <kjlubick@google.com>