* Changed one static_assert to SkASSERT in RangeSelector.cpp:42
Change-Id: I12815a8817816261bb30f5412432109ed46826fd
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/551892
Commit-Queue: Herb Derby <herb@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Change-Id: I33121076bac3ceca19c81ff9fb47e4b024a14230
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/549838
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Herb Derby <herb@google.com>
This may look like a lot, but //modules/canvaskit/BUILD.bazel
is nearly identical to how it was with gazelle:
162dfca340/modules/canvaskit/BUILD.bazel
I removed the "wasm_gm_tests" targets from it, because they
had bitrotted slightly and fixing them is its own task.
CanvasKit depends on Skottie and Particles, which depend on
the SkParagraph, SkShaper, SkUnicode, and SkResources modules.
I've structured the BUILD.bazel files in the //modules directory
in a similar fashion as the "hierarchical filegroup"
introduced in https://skia-review.googlesource.com/c/skia/+/543977
Suggested Review Order
- //modules/skottie/...
- //modules/skparagraph/...
- all other modules.
- Note that modules/canvaskit/go/gold_test_env/BUILD.bazel is
generated from gazelle, because we like how gazelle handles
golang files and deps.
- All other files in any order.
Change-Id: I0aa9e6f81dba2c00f15cae7b19fe49a2027dcf1d
Bug: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/544676
Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
gazelle ended up being more liability than asset for our C++ rules.
It required devs to manually run the command frequently (and was
easy to forget until the CQ failed). The fact that we still had to
edit the source files (e.g. the "srcs" cc_libraries) meant that
the mixture between generated and hand-written caused some
tension (see include/third_party/vulkan for a good example).
The combination of gazelle and our IWYU enforcement added several
bits of churn without any real benefit. The generated rules
also didn't help identify cases where we were not keeping tight
boundaries (e.g. non-gpu code and gpu code).
Identifying third_party deps automatically ended up being trickier
than anticipated (see the deleted //third_party/file_map_for_bazel.json)
Using the "maximum set of dependencies" worked ok, but ended up
increasing build time unnecessarily. For example, compiling
CanvasKit for WebGL always needed to compile Dawn because
SkSLCompiler.cpp sometimes needs to include tint/tint.h.
Follow-up CLs will rebuild the BUILD.bazel rules without gazelle.
Note to Reviewers:
- The only file worth manually reviewing here is bazel/Makefile.
Change-Id: I36d6fc3747487fabaf699690780c95f1f6765770
Bug: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/543976
Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
In OT-SVG `var` support is required for palette use. Even without
palette support this is needed to get the fallback color.
Change-Id: Iea8c4502b57933115f5cbf44fcc183fef19da984
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/534140
Reviewed-by: Florin Malita <fmalita@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
G3 prefers license() first.
This was done mechanically with a big find/replace
Change-Id: I8c33c7bc10a6bec42e966cad81c259954e841811
Bug: skia:13211
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/535898
Reviewed-by: Ben Wagner <bungeman@google.com>
Ran the following commands:
find -name "BUILD.bazel" -exec sed -i -e '1iload("//bazel:macros.bzl", "cc_library", "exports_files_legacy")\nexports_files_legacy()' {} +
buildifier --lint=fix --mode=fix -r .
This had the effect of making sure we can export all of our
files in G3 (until we no longer have legacy targets) and
making all of our cc_libraries shim-able.
bazel/macros.bzl has the human-contributed changes, the rest
were mechanical.
Change-Id: I8e24e30e74b038cfd072cdbe4078bfd1d213dd46
Bug: skia:13211
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/535359
Reviewed-by: Ben Wagner <bungeman@google.com>
An empty viewPort should always send everything to a point. An empty
viewBox should either draw nothing or fill the viewPort with the color
of a single point of no area.
Change-Id: I0d4f0cea3918acc4edc98043f3a7155e4e171bff
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/533809
Reviewed-by: Florin Malita <fmalita@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
The Gazelle extension does not verify the hdr/src name (yet).
Bug: skia:12541
Change-Id: Ibd9fd4663d643e864ccc6977bd3c928f722d6c3a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/533804
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
PS1 regenerates BUILD.bazel files
I suggest reviewing the deltas between PS1 and the latest
PS to focus on the interesting bits.
The changes here allow for a Vulkan-only build of HelloWorld
based on sk_app. The toughest change was properly fetching
the VisualID after removing the gl calls that used to
fill that in.
There are a few changes that fix resolution of Dawn
header files, but those won't actually be built until
a follow-on CL.
Change-Id: I54fb58b5dd7ecd4313562aed401759b3eaed53c0
Bug: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/516999
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
This CL backs out C++14 compatibility changes from
http://review.skia.org/457298 :
"2. Lack of C++17 copy elision means classes of objects constructed at
function return need a copy or move constructor even if RVO will mean it
isn't called."
Change-Id: I33a833d33b221e757bf6a6459835a7215b4e6b66
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/501240
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Change-Id: Ic664ad0134d61dcf939dcf585a81d53e29c6afcc
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/496597
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: Brian Osman <brianosman@google.com>
To make the atomic rules a bit easier to work with, in many
of the folders, this adds in cc_library rules to group
together the sources from that folder (and subfolders
where prudent). We only needs sources because those atoms
should have their headers as deps.
One issue that was pointed out is that there is currently
no way to restrict the inclusion of certain packages,
a la, `gn check`. For example, there is no mechanism from
stopping a dev from adding
#include "modules/canvaskit/WasmCommon.h"
to something in //src/core (except circular dependencies).
We can probably address that using Bazel's visibility
rules as needed:
https://docs.bazel.build/versions/main/visibility.htmlhttps://docs.bazel.build/versions/main/be/functions.html#package_group
It is recommended to look at this CL patchset by patchset.
PS1: Update gazelle command to generate rules in more folders.
PS2: A few changes to make generation work better.
PS3: The result of running make generate in //bazel
PS4: Adding the rules to build sksllex, the simplest binary I
could find in the Skia repo.
PS5: Adding the rules to build skdiff, a more complex binary.
I tried a few approaches, but ended up gravitating back
towards the layout where we have each folder/package
group up the sources. I imagine at some point, we'll have
skdiff depend on skia_core or something, which will
have things like //src/core, //src/codecs, //src/pathops
all bundled together.
PS7: Added in the groupings of sources, similar to what we had
earlier. I liked these for readability. These helped fix
up the //:skia_core build, and by extension, the CanvasKit
build.
Change-Id: I3faa7c4e821c876b243617aacf0246efa524cbde
Bug: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/476219
Reviewed-by: Ben Wagner <bungeman@google.com>
Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical]
inherit_if_needed(currentNode->fX , attrs->fX) |
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
note: cast one or both operands to int to silence this warning
Change-Id: I6d59a5c33826af29560c0e30ddf9f4e16581882c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/463896
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Florin Malita <fmalita@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Florin Malita <fmalita@google.com>
Classes of issues addressed:
1. static constexpr class variables aren't automatically inline. Already handled in a separate CL
2. Lack of C++17 copy elision means classes of objects constructed at function return need a copy or move constructor even if RVO will mean it isn't called.
3. Nested braced init no longer allowed for base classes of subclasses without constructors.
4. template static constexpr var in template class throws error about redundant initialization. Adding inline and removing defn outside of class fixes it.
5. Some places that should have been including std headers now actually need to include them.
6. No auto template parameters.
7. No lambdas in constexpr funcs.
Bug: chromium:1257145
Change-Id: Icb24c6b4ed039287fb4cf27a21a1bb7dc9821728
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/457298
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
This is in prep for compiling with -std=c++14 and -Wno-c++17-extensions
when building with clang. Chrome has encountered problems with
third_party headers that are included both in Skia and other Chrome
sources that produce different code based on whether preprocessor macros
indicate a C++14 or C++17 compilation.
In C++17 they are already inline implicitly. When compiling with C++14
we can get linker errors unless they're explicitly inlined or defined
outside the class. With -Wno-c++17-extensions we can explicitly inline
them in the C++14 build because the warning that would be generated
about using a C++17 language extension is suppressed.
We cannot do this in public headers because we support compiling with
C++14 without suppressing the C++17 language extension warnings.
Bug: chromium:1257145
Change-Id: Iaf5f4c62a398f98dd4ca9b7dfb86f2d5cab21d66
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/457498
Reviewed-by: Ben Wagner <bungeman@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
If we manage to fix all the existing cases of variable shadowing, we
could enable -Wshadow.
Change-Id: Id56c227be7c29c56d6e9253aefcd33607bb1129e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/438576
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
This is a reland of e58831cd95
Original change's description:
> Add format-specifier warnings to SkDebugf.
>
> This CL fixes up many existing format-specifier violations in Skia.
> Note that GCC has a warning for formatting nothing, so existing calls to
> `SkDebugf("")` have been removed, or replaced with `SkDebugf("%s", "")`.
> These were apparently meant to be used as a place to set a breakpoint.
>
> Some of our clients also use SkDebug with bad format specifiers, so this
> check is currently only enabled when SKIA_IMPLEMENTATION is true.
>
> Change-Id: I8177a1298a624c6936adc24e0d8f481362a356d0
> Bug: skia:12143
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/420902
> Auto-Submit: John Stiles <johnstiles@google.com>
> Commit-Queue: Brian Osman <brianosman@google.com>
> Reviewed-by: Brian Osman <brianosman@google.com>
Bug: skia:12143
Change-Id: Id3c0c21436ebd13899908d5ed5d44c42a0e23921
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/421918
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This reverts commit e58831cd95.
Reason for revert: looks like breaking a few build bots
Original change's description:
> Add format-specifier warnings to SkDebugf.
>
> This CL fixes up many existing format-specifier violations in Skia.
> Note that GCC has a warning for formatting nothing, so existing calls to
> `SkDebugf("")` have been removed, or replaced with `SkDebugf("%s", "")`.
> These were apparently meant to be used as a place to set a breakpoint.
>
> Some of our clients also use SkDebug with bad format specifiers, so this
> check is currently only enabled when SKIA_IMPLEMENTATION is true.
>
> Change-Id: I8177a1298a624c6936adc24e0d8f481362a356d0
> Bug: skia:12143
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/420902
> Auto-Submit: John Stiles <johnstiles@google.com>
> Commit-Queue: Brian Osman <brianosman@google.com>
> Reviewed-by: Brian Osman <brianosman@google.com>
TBR=brianosman@google.com,ethannicholas@google.com,johnstiles@google.com
Change-Id: I07848c1bf8992925c9498e916744d0840355a077
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:12143
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/421917
Reviewed-by: Tyler Denniston <tdenniston@google.com>
Commit-Queue: Tyler Denniston <tdenniston@google.com>
This CL fixes up many existing format-specifier violations in Skia.
Note that GCC has a warning for formatting nothing, so existing calls to
`SkDebugf("")` have been removed, or replaced with `SkDebugf("%s", "")`.
These were apparently meant to be used as a place to set a breakpoint.
Some of our clients also use SkDebug with bad format specifiers, so this
check is currently only enabled when SKIA_IMPLEMENTATION is true.
Change-Id: I8177a1298a624c6936adc24e0d8f481362a356d0
Bug: skia:12143
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/420902
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This handles the case where a filter effect input is StrokePaint or
FillPaint, but the referencing element has a 'none' paint specified
(explicitly or via parsing error, as in the original bug report).
Bug: skia:11213
Change-Id: Ie710a9fc5ccb3c24014735e01c70a0ba42c7a99d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404696
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Tyler Denniston <tdenniston@google.com>
This is in preparation for reusing the image loading + aspect ratio
mapping for <feImage>.
Change-Id: I53dcf904476aae386f672488379201524855a703
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404217
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Tyler Denniston <tdenniston@google.com>
Somewhat subtle, but we were improperly handling the override of the
default subregion via the 'width' and 'height' <fe*> attributes.
Simple example: when specifying 'x' but not 'width', previously we
would use the overridden x (subregion.fLeft = boundaries.fLeft;), but
were not updating subregion.fRight based on the new fLeft value.
Bug: skia:10841
Change-Id: I309de4f0cf50a413ea6a0e7605926a3eb6cd94e2
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404205
Commit-Queue: Tyler Denniston <tdenniston@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
The full 'display' presentation attribute [1] has a number of settings
that we likely don't want to support. However, 'display:none' has some
practical uses and is easy enough to support. This progresses some
local tests as well as a few W3C tests.
[1] https://www.w3.org/TR/SVG11/painting.html#DisplayProperty
Bug: skia:10842
Change-Id: I60fef959fb45c3cfb229b85b720dfa69fc458bc3
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/403438
Commit-Queue: Tyler Denniston <tdenniston@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Two issues:
1) we are currently computing object bounding boxes using the
RenderContext of the client resource, which can override presentation
attributes
-> introduce an OBBScope to capture not just the current OBB node but
also its original RenderContext
2) text fragments must use the root <text> bounding box for OBB-relative
units [1]
-> update SkSVGTextFragment::renderText to not override the current
OBBScope; this ensures we're using the root element scope for the
whole text subtree
[1] https://www.w3.org/TR/SVG11/text.html#ObjectBoundingBoxUnitsTextObjects
Bug: skia:11936
Change-Id: Ib48ccd3dc22639de42ea150b881a26dda72fa4bf
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/403037
Commit-Queue: Florin Malita <fmalita@chromium.org>
Commit-Queue: Florin Malita <fmalita@google.com>
Reviewed-by: Tyler Denniston <tdenniston@google.com>
Note Chrome, Firefox and Inkscape (only other viewers I tested) disagree
in smallish ways with the W3C png for filters-light-01. We're somewhere
in the middle, but likely conforming enough to call it correct.
Bug: skia:10841
Change-Id: Ia83b9936d260780148fe326b6d3b2248eef69aac
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/403036
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Tyler Denniston <tdenniston@google.com>
Introduce a helper (SkSVGRenderContext::obbTransform) and refactor all
obb clients to funnel their calls through it.
This will facilitate some follow up obb changes.
Bug: skia:11936
Change-Id: If0d81b0fc9148389c2cb4bff597057a2afa2fb1b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/402956
Reviewed-by: Tyler Denniston <tdenniston@google.com>
Commit-Queue: Florin Malita <fmalita@google.com>
https://www.w3.org/TR/SVG11/filters.html#feDistantLightElement
(specular lighting only in this CL)
Tests filters-specular-01-f and filters-light-02-f should be passing
now. Note that our filters-light-02 result matches the behavior of
Chrome and Firefox, but is different than the official W3C png. We
currently think the test is somewhat poorly written, so we are
comfortable matching the output of Chrome and Firefox.
Bug: skia:10841
Change-Id: Id9517c8594a3826e5d98685d1e7d1d1b3d3cdf51
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/402582
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Tyler Denniston <tdenniston@google.com>
In the build there are some defaults which actually apply to every
use of a built-in target type, but there are some (particularaly
warnings) which apply only to targets controlled by Skia. Currently
these unwanted defaults are magically known to exist and removed
wherever they are not wanted. Instead, create 'skia_' prefixed target
templates and apply these defaults to those instead.
Change-Id: I3a2afb53c7205a2e2748d1cfad46319f2e93d3b3
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/385516
Commit-Queue: Ben Wagner <bungeman@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
