These changes reduce failing targets for skia_unittest when adding
"//build/config/compiler:prevent_unsafe_narrowing" to component("skia")
from 588 to 484 on my local Mac build.
Bug: chromium:1292951
Change-Id: Ice8210e1a2f038feb84184c88e6a34f52168952f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/552376
Commit-Queue: Greg Daniel <egdaniel@google.com>
Auto-Submit: Peter Boström <pbos@chromium.org>
Reviewed-by: Greg Daniel <egdaniel@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Change-Id: I07c0cb63286cb2c74853a49a44a9ee5ae7b994c9
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/557102
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This CL adds two new APIs to SkCanvas: getBaseProps, and getTopProps.
SkCavas::getBaseProps is functionally identical to getProps, but returns
the SkSurfaceProps by value, rather than via an 'out' parameter.
SkCanvas::getProps is now considered deprecated.
SkCanvas::getTopProps returns the 'currently active' SkSurfaceProps,
i.e., it returns the props from the "top device". This is useful
because the SkSurfaceProps can change when creating new layers.
Bug: skia:13483
Change-Id: Ia1d9a10ffdd929427f1f2c0a7c4ba6965d4bd3c0
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/554736
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Auto-Submit: Ian Prest <iapres@microsoft.com>
This has been replaced by findOrCreateRuntimeEffectSnippet.
Change-Id: I26e1f85c74071b14b75ab86410e4cc30a81bf873
Bug: skia:13405
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/552716
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
SkTypes.h was found exporting <stddef.h> and <stdint.h>.
Thus if a Skia file includes SkTypes.h, it did not need
to include either of those files to use things like
size_t or uint8_t respectively. [1]
This also resulted in strange IWYU warnings like:
warning: size_t is defined in "include/core/SkTypes.h", which isn't directly #included.
Thus, this CL removes those additional exports, and as a result,
adds many more includes of <cstddef> and <cstdint>.
The second change this CL is to not use the default IWYU
mappings which are hard-coded into IWYU [2]. These defaults
are valid, but make suggestions for the C version of
headers and not the C++ ones (i.e. <stddef.h> over <cstddef>).
To make these recommendations align better with our preferred
style (the C++ ones), we use IWYU with --no_default_mappings
and then have to expand our existing mappings to better deal
with how IWYU would resolve some of these headers.
[1] https://codereview.chromium.org/1207893002/#msg49
[2] 4c0f396159/iwyu_include_picker.cc (L1221-L1234)
Change-Id: Iafebe190f8f3e86f252147b9f538c182bcc34af4
Bug: skia:13052
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/555516
Auto-Submit: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Also expose a size() function on the public IB and VB types.
Bug: skia:12720
Change-Id: Ibeccf6d2d6ba411e9e77be582d0cb1622bc76ccd
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/555005
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Change-Id: I028bd133778d14edcb22ccef0c35c5a8e3d7d552
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/554516
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
This will make our Bazel rules in G3 easier to use.
We will have to clean up a lot of clients (and this still
might require a manual G3 roll to land to account for the
source files).
Eventually, we will be able to delete the old one
//include/third_party/skcms and //third_party/skcms
Bug: skia:12451, b/237076898
Change-Id: I9fd55607cbb7e1196d175aa8f140e99a73505c89
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/554056
Reviewed-by: Brian Salomon <bsalomon@google.com>
Bug: skia:13430
Change-Id: I6c577b459bc3a699e6c660d21d2b119643fe1f88
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/553877
Reviewed-by: Eric Boren <borenet@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Part of an ongoing effort to move chromium away from SkColor and towards SkColor4f: crbug.com/1308932
Many tests use SkBitmap::getColor to validate pixels, this means that we're now in a state where we draw using float colors but then have to validate the operation with the nearest integer color value. As can be seen in SoftwareRendererTest.SolidColorQuad.
Change-Id: Ic4493e578c8f4066c2439f1e793eef10eb4f4056
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/553797
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Change-Id: Id58bf93098fa62f621614937a2d1524790f73f58
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/551708
Commit-Queue: Herb Derby <herb@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Enable passing in a feature-test function that returns a Boolean
with the intention of being able to use it in FreeType library
initialisation.
See also:
https://gitlab.freedesktop.org/freetype/freetype/-/merge_requests/168
Bug: skia:13448
Change-Id: I6c985201552b54f2fa99e911265b7303ff8b2897
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/551637
Commit-Queue: Dominik Röttsches <drott@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Florin Malita <fmalita@google.com>
Added changes for public.bzl
This is a reland of commit 4a375fe213
Original change's description:
> Move SkSubRun to src/text
>
> Change-Id: I5c1040b8236dc792de20495a3fea3c0be6e31c20
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/549847
> Reviewed-by: Brian Osman <brianosman@google.com>
> Commit-Queue: Herb Derby <herb@google.com>
Change-Id: I86e342a416a3c97bf972c496b93b37e35cd09c19
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/550496
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Herb Derby <herb@google.com>
According to https://en.cppreference.com/w/cpp/container/span/span (2),
it is undefined behavior if [first, first + count) is not a valid
range, so it is standards-conforming to assert on this span.
This caught one case in GlyphRun where we were creating an invalid
span (which was apparently harmless in practice).
Change-Id: Ia0661b3bd13c2c5773492960eea11b1a294072d5
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/550499
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Bug: skia:12701
Change-Id: I53bbabb2aba44e3bfc215df81dae1ae59d149263
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/544319
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
[[maybe_unused]] is built in to C++17.
Change-Id: I5e49d0801878fd9fbca62ab28080aa856e33ca79
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/550500
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Herb Derby <herb@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Change-Id: I5c1040b8236dc792de20495a3fea3c0be6e31c20
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/549847
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Herb Derby <herb@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>
Use template guides for deducing the type needed by the CTOR.
This allows SkSpans to be deduced when things like vector,
array, A[], etc. are passed as parameters without using SkMakeSpan.
Change-Id: Ieedcbddc8d40281f819b0c798acd178a12a05891
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/549568
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Herb Derby <herb@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
Change-Id: I7a4cd8e2c629ba53e40adc379ea92f86f70d11da
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/549857
Commit-Queue: Greg Daniel <egdaniel@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
Auto-Submit: Jim Van Verth <jvanverth@google.com>
Use std::size and std:data to get needed values.
Add a SkMakeSpan for initializer_list.
Change-Id: I43b4b2391323c84b3d6aad22ac4775487c6d5570
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/549565
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Herb Derby <herb@google.com>
This adds a new SkShaderType for runtime shaders, but it doesn't do
anything interesting yet; for now, we draw solid magenta as a
placeholder.
Change-Id: If0e4af9000d97fcf1184fbed004a64fff8fa4e63
Bug: skia:13405
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/548477
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Change-Id: I27eb99450b2b261a4688c62d91a9002dfe7d14df
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/548484
Auto-Submit: Herb Derby <herb@google.com>
Commit-Queue: Herb Derby <herb@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Change-Id: I0925a52cc3a504c95ec4453e74c4580ce692275c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/548896
Reviewed-by: Eric Boren <borenet@google.com>
Reviewed-by: Heather Miller <hcm@google.com>
Auto-Submit: Heather Miller <hcm@google.com>
Commit-Queue: Eric Boren <borenet@google.com>
Bug: skia:12701
Change-Id: Ibf7b4ac280eb853e3f5d786bd188ae0ac208609b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/545367
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
SkMesh now takes SkData that contains the uniform values.
Change-Id: I286e7559ba692ce15925a54f59c2e829b6b5448f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/546096
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Bug: skia:12701
Change-Id: I88a12b776cf9b14d0c0a94ae777b85d9592696a7
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/544318
Commit-Queue: Robert Phillips <robertphillips@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Bug: skia:12701
Change-Id: I4209a4741a957a4dc60ad6669fc164a2d5993676
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/545720
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
This CL adds the ability to add child combinations to the top-level
combinations added to the builder.
Bug: skia:12701
Change-Id: Ibe182c631bb9811d82e314ba58823b1708058165
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/542299
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
In general, SkSurfaceProps is only needed when rendering text. However,
there are several existing APIs that don't allow SkSurfaceProps to be
passed in by the user.
This change adds new SkSurfaceProps parameters to several public-facing
APIs:
1. SkRasterHandleAllocator::MakeCanvas
-- The props are used by the canvas whenever text is rendered.
2. SkImage::MakeFromPicture and SkImageGenerator::MakeFromPicture
-- The props are used to render any text in the SkPicture object.
Change-Id: Ic48e8a30bb12b3170415c644de1a007b5eefb818
Bug: skia:13369
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/545396
Reviewed-by: Ben Wagner <bungeman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Organization v3.5, if we are keeping track :)
This splits the "srcs" filegroup into "srcs" and "private_hdrs",
and renames "hdrs" to "public_hdrs".
To assist with the split, I created the macro split_srcs_and_hdrs.
Rather than keep two separate lists of header and source files,
I figured it would be easiest, at least for the common case,
to keep one list of files and then have a for loop split them
apart. I've tried to be consistent with having the list
of files be named with a _FILES suffix - maybe we can use this
as a marker to generate .gni files in the future?
Suggested review order:
- //bazel/macros.bzl. Note this needs a corresponding
G3 change (http://cl/452279799) as well. The exports_files_legacy
change is the better approach to something I manually
handled yesterday when fixing the G3 roll.
- //BUILD.bazel to see the new target skia_internal and
the previous skia_core renamed to skia_public.
- //src/core/BUILD.bazel to see a typical usage of
split_srcs_and_hdrs.
- //include/... to see the change to public_hdrs and
private_hdrs
- //src/... to see many more usages of split_srcs_and_hdrs
- //tools/... to see changes to skia_internal where
appropriate.
- Everything else. Note that //modules/... might also need
to be built with skia_internal instead of skia_public,
but we can fix that up later, if necessary.
Change-Id: Ie1cc969455d97b029b2d77faa222c4a9bad70671
Bug: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/545716
Reviewed-by: Ben Wagner <bungeman@google.com>
Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
Currently there is no way to specify the data that is bound to them.
That will come in later changes.
Bug: skia:12720
Change-Id: I3301a825486469396a13a4095b66d9e0b81f183b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/543716
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
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>
