The primary goal of this organization structure is to keep
our top level BUILD.bazel file short, with as little logic
as feasible. The logic required to control which files to
include, which third_party deps are needed, what system libraries
should be linked again, etc, should be in the BUILD.bazel
file best should be as close to the affected files as feasible.
In essence, we use filegroup() rules to bubble up the files
needed to build Skia (all as one big cc_library call) and
cc_library rules to bubble up the other components needed to build.
For example, //src/ports/SkFontHost_FreeType.cpp needs FreeType,
but only if we are compiling Skia with that type of font
support. With the new organization structure in this CL,
//src/ports/BUILD.bazel should have the logic that determines
if the cpp file should be included in the build of Skia and
if it is, that the Skia build should depend on //third_party:freetype2
Another example is //src/gpu/ganesh/BUILD.bazel, which
chooses which of the dawn, gl, vulkan, etc backend sources,
and the associated dependencies to include in the build.
It does not specify what those are, but delegates to the
BUILD.bazel files in the subdirectories housing the
backend-specific code.
The structure guidelines for BUILD.bazel files are as follows:
- Have a filegroup() called "hdrs" (for public headers) or
"srcs" (for private headers and all .cpp files) that is
visible to the parent directory. This should list the
files from the containing directory to include in the
build.
See //include/core/BUILD.bazel and //src/effects/BUILD.bazel
as examples.
- filegroup() rules can list a child directory's "hdrs"
or "srcs" in their "srcs" attributes, but should not contain
select statements pertaining to child directory files.
See //include/gpu/BUILD.bazel and //src/gpu/ganesh/BUILD.bazel
as examples.
- May have a cc_library() called "deps". This can specify
dependencies, cc_opts, and linkopts, but not srcs or hdrs. [1]
See //src/codec/BUILD.bazel as an example. These should
be visible to the parent directory.
- "hdrs", "srcs", and "deps" for the primary Skia build
(currently called "skia_core") should bubble up through
//include/BUILD.bazel and //src/BUILD.bazel, one directory
at a time.
This CL demonstrates a very basic build of Skia with many features
turned off (CPU only, no fonts, no codecs). Follow-on CLs will
add to these rules as more targets are supported. See bazel/Makefile
for the builds that work with just this CL.
Suggested Review Order:
- //BUILD.bazel to see the very small skia_core rule which
delegates all the logic down stack. Note that it has a
dependency on //bazel:defines_from_flags which will set
all the defines listed there when compiling all the
.cpp and .h files in skia_core *and* anything that depends
on skia_core, but *not* //src:deps.
- //include/BUILD.bazel and other BUILD.bazel files in the
subdirectories of that folder. Note that the filegroups in
//include/private/... are called "srcs" to be similar to
how Bazel wants "private headers" to be in the "srcs" of
cc_library, cc_binary, etc. and only public headers are
to be in "hdrs" [2].
- //src/BUILD.bazel and other BUILD.bazel files in the
subdirectories of that folder. //src/gpu/ganesh/...
will be filled in for dawn, vulkan, and GL in the next CL.
- //PRESUBMIT.py, which adds a check that runs buildifier [3]
on modified BUILD.bazel files to make sure they stay
consistently formatted.
- //bazel/... to see the new option I added to make sksl
opt-in or opt-out, so one could build Skia with sksl,
but not with a gpu backend.
- Misc .h and .cpp files, whose includes were removed if
unnecessary or #ifdef'd out to make the minimal build
work without GPU or SkSL includes.
- //bazel/Makefile to see the builds that work with this CL.
[1] Setting srcs or hdrs is error-prone at best, because those
files will be compiled with a different set of defines than
the rest of skia_core, because they wouldn't depend on
//bazel:defines_from_flags.
[2] https://bazel.build/reference/be/c-cpp#cc_library.hdrs
[3] https://github.com/bazelbuild/buildtools/releases
Change-Id: I5e0e3ae01ad42d672506d5aad1239f2512188191
Bug: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/543977
Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
Reviewed-by: Ben Wagner <bungeman@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>
Change-Id: I7ef9d50eeb49076dbd71fd7070a0f849085c4dc7
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/543978
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
In PDF there are two different physical encodings of strings (as a
sequence of bytes). There is the literal string encoding which is
delimited by '(' and ') which stores the bytes as-is except for '(',
')', and the escape character '\' (which can introduce octal encoded
bytes). There is also the hex string encoding delimited by '<' and '>'
and the bytes are encoded in hex pairs (with an implicit '0' at the end
for odd length encodings).
The interpretation of these bytes depends on the logical string type of
the dictionary key. There is a base abstract (well, almost abstract
except for legacy purposes) string type. The subtypes of the string type
are `text string`, `ASCII string`, and `byte string`. The `text string`
is logically further subtyped into `PDFDocEncoded string` and `UTF-16BE
with BOM`. In theory any of these logical string types may have its
encoded bytes written out in either of the two physical string
encodings.
In practice for Skia this means there are two types of string to keep
track of, since `ASCII string` and `byte string` can be treated the
same (in this change they are both treated as `byte string`). If the
type is `text string` then the bytes Skia has are interpreted as UTF-8
and may be converted to `UTF-16BE with BOM` or used directly as
`PDFDocEncoded string` if that is valid. If the type is `byte string`
then the bytes Skia has may not be converted and must be written as-is.
This means that when Skia sets a dictionary key to a string value it
must, at the very least, remember if the key's type was `text string`.
This change replaces all `String` methods with `ByteString` and
`TextString` methods and updates all the callers to the correct one
based on the key being written.
With the string handling corrected, the `/ActualText` string is now
emitted with this new common code as well for better output and to
reduce code duplication. A few no longer used public APIs involving
these strings are removed. The documentation for the URI annotation is
updated to reflect reality.
This change outputs `UTF-16BE with BOM` with the hex string encoding
only and does not attempt to fix the literal string encoding which
always escapes bytes > 0x7F. These changes may be attempted in a
separate change.
Bug: chromium:1323159
Change-Id: I00bdd5c90ad1ff2edfb74a9de41424c4eeac5ccb
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/543084
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
Reviewed-by: Herb Derby <herb@google.com>
SK_SUPPORT_GPU needed to be set to 1, and SK_GRAPHITE_ENABLED should
be checked to see if it's defined, not its value.
Change-Id: Ib762c590ceaa570ec98a76558657bbcee672c254
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/543080
Reviewed-by: Greg Daniel <egdaniel@google.com>
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
This is cleanup left over from a prior CL's review. We will want to
use the combination builder outside of graphite.
This CL is mainly just moving stuff around except for the addition
of the SkCombinationBuilder.buildCombinations method and CreateKey
more accessible outside of Graphite.
Bug: skia:12701
Change-Id: If2cae6fcff5670e488bc14473b7b1d2f9b1fecd7
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/543196
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
This also adds support for making a Resources unbudgeted state when it
is pulled out of the cache to be used for an SkImage or Surface. It
then puts the resources back as budgeted when returned to the cache.
Bug: skia:12754
Change-Id: I469ace602aa6f5f708b82655e94557ff8ad45a72
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/538046
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
Bug: skia:13118
Change-Id: Id4afcfeeb9a5b44a0e2cb24b70c76a81ec5daaea
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/542300
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Bug: skia:13329
Change-Id: I9992cd5149e50f9a998af712984a82e5d952d58b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/541936
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Also fix various compile issues if you try to compile w/o SkSL.
Change-Id: I9a5a176254184a04f4c8af93a8dca958c8c69fee
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/542142
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Move allocation of Caps::fShaderCaps to the base class,
and add a finishInitialization method, like GrCaps.
Change-Id: I5353a03afea29390be3cce1fb371374532f5af3c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/541073
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Jim Van Verth <jvanverth@google.com>
This is a reland of commit 69fecd6c2d
Original change's description:
> Add SkCapabilities object
>
> This describes the capabilities of a particular Skia rendering context
> (GPU context, or the CPU backend). At the moment, it only contains the
> supported SkSL version (with a new enum added to specify the current
> value as "100" and a new ES3 value as "300".
>
> SkCapabilities can not be retrieved from an SkCanvas - the client must
> have a concrete way of knowing what their destination device that will
> do the actual rendering is (GrCaps or SkSurface).
>
> This CL doesn't make use of the SkCapabilities yet, that's coming in
> follow-up CLs that alter the SkSL compiler and SkRuntimeEffect API.
>
> Bug: skia:11209
> Change-Id: I4e9fd21ff7ffd79f1926c5c2eb34e10b3af4bc9b
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/537876
> Reviewed-by: Michael Ludwig <michaelludwig@google.com>
> Reviewed-by: Brian Salomon <bsalomon@google.com>
> Commit-Queue: Brian Osman <brianosman@google.com>
> Reviewed-by: John Stiles <johnstiles@google.com>
Bug: skia:11209
Change-Id: If76343a8a536ade25f6b3d80e0885c7bc47d2adf
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/540919
Reviewed-by: John Stiles <johnstiles@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This reverts commit 69fecd6c2d.
Reason for revert: Why do we even bother separating include from src?
Original change's description:
> Add SkCapabilities object
>
> This describes the capabilities of a particular Skia rendering context
> (GPU context, or the CPU backend). At the moment, it only contains the
> supported SkSL version (with a new enum added to specify the current
> value as "100" and a new ES3 value as "300".
>
> SkCapabilities can not be retrieved from an SkCanvas - the client must
> have a concrete way of knowing what their destination device that will
> do the actual rendering is (GrCaps or SkSurface).
>
> This CL doesn't make use of the SkCapabilities yet, that's coming in
> follow-up CLs that alter the SkSL compiler and SkRuntimeEffect API.
>
> Bug: skia:11209
> Change-Id: I4e9fd21ff7ffd79f1926c5c2eb34e10b3af4bc9b
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/537876
> Reviewed-by: Michael Ludwig <michaelludwig@google.com>
> Reviewed-by: Brian Salomon <bsalomon@google.com>
> Commit-Queue: Brian Osman <brianosman@google.com>
> Reviewed-by: John Stiles <johnstiles@google.com>
Bug: skia:11209
Change-Id: I3bc843b0abf154dbaecb209b251f80741757bf70
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/540858
Commit-Queue: Brian Osman <brianosman@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
I keep bumping into the need for this
Change-Id: I69384f7d590c163fd6244bdc64cc5e48450fecd4
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/540171
Commit-Queue: Robert Phillips <robertphillips@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This describes the capabilities of a particular Skia rendering context
(GPU context, or the CPU backend). At the moment, it only contains the
supported SkSL version (with a new enum added to specify the current
value as "100" and a new ES3 value as "300".
SkCapabilities can not be retrieved from an SkCanvas - the client must
have a concrete way of knowing what their destination device that will
do the actual rendering is (GrCaps or SkSurface).
This CL doesn't make use of the SkCapabilities yet, that's coming in
follow-up CLs that alter the SkSL compiler and SkRuntimeEffect API.
Bug: skia:11209
Change-Id: I4e9fd21ff7ffd79f1926c5c2eb34e10b3af4bc9b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/537876
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Change-Id: Iafd9cf15ac3c42bda7fa6b6857a82dc2eae6d234
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/540296
Reviewed-by: Heather Miller <hcm@google.com>
Commit-Queue: Eric Boren <borenet@google.com>
Commit-Queue: Heather Miller <hcm@google.com>
Simplify the fields used by each, and simplify the CTORs in
the original SkGlyphRunPainter.
TODO: come up with a better no gpu method. Eventually, this
should be pure Sk. There is no need for GPU to make and
serialize a slug only to draw them.
Change-Id: I446fe0c285ae778a14b30e09c8a2cff3cd1a56c1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/538896
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Herb Derby <herb@google.com>
Auto-Submit: Herb Derby <herb@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
The client passes a GrDirectContext* when creating a vertex or index
buffer. The data is copied to a GPU accessible buffer object
and the client gets a Skia object that may only be used with the GrDirectContext. The GPU backend draws directly from the buffer, thereby
avoiding the per-draw copy cost.
The underlying Ganesh object is freed in a thread-safe manner using an
existing message bus to perform a delayed unref in GrResourceCache.
Bug: skia:12720
Change-Id: If2578fbbf094874967a294a095b3bc5d7616d73a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/527918
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
SkCustomMesh is a class with factory functions. Vertex and index
data are stored in buffer objects rather than raw pointers. User can
provide offsets into the buffers.
Currently the buffers are always CPU backend and are uploaded to the
GPU on each draw. However, buffer the creation API takes a
GrDirectContext which in the future will be used to create a GPU-backed
buffer specific to the passed context.
Bug: skia:12720
Change-Id: If1bb8110f0f2f219b030f9682ab844f1f2207d9f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/527917
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Brian Salomon <bsalomon@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>
This is a reland of commit e6f23f98de
Original change's description:
> Reland "Add anisotropic option to SkSamplingOptions."
>
> This is a reland of commit 9be2d572d4
>
> Original change's description:
> > Add anisotropic option to SkSamplingOptions.
> >
> > Implement on GPU.
> >
> > Bug: skia:13036
> > Change-Id: I35d760596c4f8faaec27fccf284b70802fcf3f9b
> > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/524757
> > Commit-Queue: Brian Salomon <bsalomon@google.com>
> > Reviewed-by: Brian Osman <brianosman@google.com>
> > Reviewed-by: Michael Ludwig <michaelludwig@google.com>
>
> Bug: skia:13036
> Change-Id: I3e411aae389dc880ce32bba78852705059fb88b0
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/535197
> Reviewed-by: Brian Osman <brianosman@google.com>
> Commit-Queue: Brian Salomon <bsalomon@google.com>
Bug: skia:13036
Change-Id: Icb2513cea6c4ec4cec934f78c66071081c232960
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/535437
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@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>
This is a reland of commit 9be2d572d4
Original change's description:
> Add anisotropic option to SkSamplingOptions.
>
> Implement on GPU.
>
> Bug: skia:13036
> Change-Id: I35d760596c4f8faaec27fccf284b70802fcf3f9b
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/524757
> Commit-Queue: Brian Salomon <bsalomon@google.com>
> Reviewed-by: Brian Osman <brianosman@google.com>
> Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Bug: skia:13036
Change-Id: I3e411aae389dc880ce32bba78852705059fb88b0
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/535197
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Implement on GPU.
Bug: skia:13036
Change-Id: I35d760596c4f8faaec27fccf284b70802fcf3f9b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/524757
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Change-Id: I28ef42ff417faf98eb1f124d4a1987b6cc4a609f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/530456
Auto-Submit: Eric Boren <borenet@google.com>
Reviewed-by: Ravi Mistry <rmistry@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Change-Id: I3a9e9e90b0ac1b1099830eaca06506bcce794144
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/530055
Commit-Queue: Brian Salomon <bsalomon@google.com>
Auto-Submit: Brian Salomon <bsalomon@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
Previously just the base level was uploaded and the level contents
were generated on the GPU.
showmiplevels_explicit now works on GPU.
Bug: skia:11983
Change-Id: I96ed8a7ad90a8252f55a736cb6146eec9b2a3ad1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/521356
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
There seems to be a copy-paste issue with the documentation for the
return value of SkFont::countText. SkFont::countText returns the number
of glyphs, measureText returns the sum of the default advances.
Change-Id: Id3c9008c20e7b4b8ad4f1d834df19183a9b2bf1e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/530046
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
https://en.cppreference.com/w/cpp/container/span/subspan
The real std::span::subspan in C++20 allows the "count" argument to
default to `std::dynamic_extent` (a fancy way of spelling ~0U). I didn't
think it would be worth adding `skstd::dynamic_extent`, but I did have
a use for an unbounded subspan, so I added a single-argument version to
SkSpan.
Change-Id: I297cc452cf2db727a3f9869ff8f46f3527e19370
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/529603
Reviewed-by: Arman Uguray <armansito@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
This is a reland of commit ae5e846047
Original change's description:
> [graphite] Move Graphite into Skia base directories.
>
> Change-Id: Ie0fb74f3766a8b33387c145bd1151344c25808cb
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/528708
> Reviewed-by: Kevin Lubick <kjlubick@google.com>
> Reviewed-by: Greg Daniel <egdaniel@google.com>
> Commit-Queue: Jim Van Verth <jvanverth@google.com>
Change-Id: Ia575fd49206ad0b665a6a9153317e738bb321446
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/529059
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Change-Id: Ie0fb74f3766a8b33387c145bd1151344c25808cb
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/528708
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Change-Id: I484067cb1f6025dc9e6770c51c99bfc2c5925652
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/528365
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
IWYU doesn't always understand that we want defines to come from
certain files, so we add a pragma to force it.
This also adds an extra entry to known_good_builds so I don't miss
this type of thing again when building locally.
Change-Id: I2321ea95edfc6a4506d51a011983965eb9bdf1c0
Bug: skia:13052
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/528164
Reviewed-by: John Stiles <johnstiles@google.com>
Owners-Override: Kevin Lubick <kjlubick@google.com>
While I was fixing up Chrome's uses, I found some failures
there that I did not see in Skia, and tracked them down
to a few other places where we include SkColorSpace
and it is not strictly necessary
- SkCustomMesh.h
- GrColorInfo.h
- GrColorSpaceXform.h
- SkColorSpaceXformSteps.h
For these files (and their .cpp files), I added enforcement
of include-what-you-use, and then fixed the myriad of places
which were depending on these transitive includes.
One change to help Chrome is the manual overloads of
SkImage::MakeFromAdoptedTexture instead of using default
parameters. This makes it so callers of that function
do not need to include SkColorSpace if they were going
to pass nullptr for it anyway.
Bug: skia:13052
Change-Id: I16bf8ed5e258225d887f562f2c189623b1ca9c23
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/527056
Reviewed-by: Robert Phillips <robertphillips@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
The implementation is inconsistent across CPU and GPU.
CPU currently always implements kStrict even when kFast is passed.
For mipmapping this means computing a set of levels from the subset,
which is an expensive.
GPU limits the texture sampling coordinates to the subset in the
base level. However, higher level mipmap pixels that map back to
a footprint outside the subset are still sampled. So GPU pays a
higher shader complexity cost without really providing the benefit
of kStrict.
We are adding anisotropic filtering, which will not work well with
kStrict, and thus will also be disabled by kStrict.
Must land after https://chromium-review.googlesource.com/c/chromium/src/+/3571661
Bug: skia:10481
Bug: skia:13078
Bug: skia:13036
Canary-Chromium-CL: 3571661
Change-Id: I011b8698a3f9fafa9b819486873c8ff54df6299e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/527284
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
We already do this for cached SkSurface snapshot images. However,
sharing the SkPixelRef among any SkImage_Rasters with different
SkMipmaps interacts badly with SkImage texture caching and likely
other image caches.
Bug: skia:11983
Change-Id: I07bb7a93ffb79afb7f8268cd5159ee22f58da1e7
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/526456
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
