This stopped being relevant when color management was no longer tied to
linear blending.
Change-Id: I2171c5c74d75cf2f78c1ff9fac62584a305c71ce
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/282158
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
SK_SUPPORT_LEGACY_DIDCONCAT44
Change-Id: Ie208c245d7121fddc693a7d3c5d6866441c27433
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/281864
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Reed <reed@google.com>
Supports buffer creation and destruction.
Bug: skia:9935
Change-Id: I6d8c6d67209a8857989a9384818272e7108177ad
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/281577
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
The CheckGeneratedFiles bot only required rewriting
.gn files, while the presubmit wants both .gn and .gni files.
It also appears that the #includes rewrite script runs on
both the presubmit and CheckGeneratedFiles bots.
These presubmits run on the CQ before landing right?
If so, no need for them in the CheckGeneratedFIles bot at all.
And of course, format .gni files.
Change-Id: Icd4526d62f85088862ad93566cc9ace11dc3e33f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/281505
Reviewed-by: Eric Boren <borenet@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Change-Id: I16c392abe36d7aac7be2dee47116d873a8787afd
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/281378
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Bug: skia:9984
Change-Id: Ib79cf2509f5f92672cbb0b6060b8b33f99e9ac28
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/281162
Commit-Queue: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Reed <reed@google.com>
Auto-Submit: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Reed <reed@google.com>
This prevents a build failure if Skia is installed to a path with a space in it.
Change-Id: I3f9a6d435971720a32c3ac14c9eb144f2da563a3
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/280183
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Change-Id: I2d19c4f0ff1439dcd923a3064eb3ba78432a5113
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/281043
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
Makes new GN happy.
Change-Id: Id87e44d46772c6f147e0150f8c586fdd0a97504d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/280904
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Bug: skia:9935
Change-Id: I4c2d70f69e30f78caca0f49629880565f178f495
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/280609
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
This reverts commit e990fcc4b0.
Reason for revert: Build-Win-Clang-x86_64-Release-Shared
Original change's description:
> Enable deprecated-copy-dtor warning.
>
> In C++11 a user declared destructor still requires the compiler to
> implicitly default the copy constructor and copy assignment operator,
> but this is deprecated. Note that a user declared destructor suppresses
> the move constructor and move assignment operator; a user declared
> destructor exists if any '~Foo' method declaration appears inside
> 'class Foo' (even if defaulted); if the copy and move operations are the
> same then copy operations that take 'const Foo&' will do fine double
> duty as move operations.
>
> Clang seems to have an issue with this warning, in that it does not
> appear to distinguish between compiler defaulted and user defaulted
> destructors. As a result, it does not always warn when it should.
> There may yet be places in the code where a move operation is desired
> but may be suppressed because the implicitly defaulted moves are not
> declared because a destructor has been declared.
>
> This wraps dawn and shaderc configs in 'third_party' so that their
> headers will be included through '-isystem' in order to avoid the
> warnings generated by including their headers.
>
> Change-Id: I681524cd890d86305aa99b6b765a52113b4dfa4b
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/280406
> Reviewed-by: Mike Klein <mtklein@google.com>
> Reviewed-by: Brian Salomon <bsalomon@google.com>
> Commit-Queue: Ben Wagner <bungeman@google.com>
TBR=mtklein@google.com,bsalomon@google.com,bungeman@google.com
Change-Id: Icd6a2487637d21fcf7c4c7ab7cba7a8adfda5afd
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/280836
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
In C++11 a user declared destructor still requires the compiler to
implicitly default the copy constructor and copy assignment operator,
but this is deprecated. Note that a user declared destructor suppresses
the move constructor and move assignment operator; a user declared
destructor exists if any '~Foo' method declaration appears inside
'class Foo' (even if defaulted); if the copy and move operations are the
same then copy operations that take 'const Foo&' will do fine double
duty as move operations.
Clang seems to have an issue with this warning, in that it does not
appear to distinguish between compiler defaulted and user defaulted
destructors. As a result, it does not always warn when it should.
There may yet be places in the code where a move operation is desired
but may be suppressed because the implicitly defaulted moves are not
declared because a destructor has been declared.
This wraps dawn and shaderc configs in 'third_party' so that their
headers will be included through '-isystem' in order to avoid the
warnings generated by including their headers.
Change-Id: I681524cd890d86305aa99b6b765a52113b4dfa4b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/280406
Reviewed-by: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
Changes the GrD3DTextureResourceInfo member in GrD3DBackendSurfaceInfo
to be a unique_ptr<> so we can use forward refs.
This will allow us to use a shared_ptr variant to manage the
ID3D12Resource on GrD3DResourceResourceInfo, without polluting
client files with Windows definitions. Clients can use GrD3DTypes.h
to get the full declarations, GrD3DTypesMinimal.h for only the forward
references.
Bug: skia:9935
Change-Id: I075a3fc608bf6767dae202efd8cbf06cdd4a9457
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/280602
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Change-Id: I60a3569b47b599b710c0f3a9522241748f15360d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/280409
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Reed <reed@google.com>
Flutter's code has been updated so these can all be removed
Change-Id: Id3b778158fce175efd23b80a1d1245106c848501
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/279840
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
GCC 9 warns about this pessimizing-move. It isn't clear why clang isn't
as well.
GCC 9 has a working redundant-move diagnostic. Clang has an old (C++11
style) redundant-move diagnostic which only warns when moving a
parameter. The GCC warning conflicts with Clang's
return-std-move-in-c++11, which we want to keep until we can drop
support for older compilers. So just disable redundant-move warnings
until we can remove return-std-move-in-c++11.
This change allows us to compile without warnings on gcc 9.3.0.
Change-Id: If21fcfb2944ce49e27fc84d40805752895ae68cf
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/279958
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
Change-Id: If918db1153f6b5bf7057e00f3d36113fc88d889d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/279919
Commit-Queue: Greg Daniel <egdaniel@google.com>
Reviewed-by: Jim Van Verth <jvanverth@google.com>
It wants a blank line before a comment, even though the comment isn't a
break.
Change-Id: I6a2988719942e5e72142b8484182c128392a4be8
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/279842
Commit-Queue: Ben Wagner <bungeman@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Auto-Submit: Ben Wagner <bungeman@google.com>
It was only used for the sRGB color filter, and GrColorSpaceXformEffect
works just as well.
Change-Id: I6727d2bf7cc60a876742b0dbd980d8ef40ae16fe
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/278788
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Unfortunately in clang 'deprecated' is both a set of warnings (at least
one of which we don't want) and a group of warnings (most of which we do
want). Leave the top level disabled, but re-enable all the warnings in
the group.
Most of the code changes are for the deprecated-copy diagnostic. In
C++11 implementing a copy constructor xor copy assignment operator
the default implementation of the other is still required to be the
default but is deprecated (the compiler can warn against doing this).
The idea is that if there was a need for a non-default copy constructor
or copy assignment operator then both should be implemented explicitly,
since it is unlikely that the default will do what is expected.
Note that the deprecated-copy-dtor has not yet been enabled as there
will need to be a lot more work to enable this diagnostic. Similar to
deprecated-copy, in C++11 when implementing a destructor the copy
constructor and copy assignment operator are still defaulted if not
declared, but this is also deprecated. The idea here is that if some
special handling is needed to destroy the object there is probably some
need to do something non-trivial when copying the object (or copying
should be disallowed).
Also, there are still some deprecated-declarations to clean up on
Android and Mac.
Change-Id: I5fc4b62713220e6f7d3724fd7342b4c8c74a3c67
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/278916
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
Bug: skia:9935
Change-Id: I91b6218946ba04e893adaec3c0077653a62efe2e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/279136
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Also renames GrD3DSurfaceResource to GrD3DTextureResource. This makes
things consistent with our naming convention in Vulkan, and with the
terminology used in Direct3D.
Bug: skia:9935
Change-Id: I6e6d2066ac70eb8a0d63c1b5731f31851a3017d5
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/279338
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Ambiguity has come up re: what "tessellation" means in Ganesh. I
believe that, in the context of a graphics library, "tessellation"
should refer to the hardware pipeline feature of submitting patches
and tessellating them on the GPU. This CL therefore renames classes
that triangulate things on the CPU to call it "triangulation".
Change-Id: Ic8515ea6a33000f1b638a852d5122bc9bd6b38f2
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/279236
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Change-Id: I62880a83d9b59d42c6491125e2a62338d2ce757f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/279200
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Adds a "viewer" option to the build system that brings in tooling code
and sample code. Adds a very simple "MakeSlide" binding that knows
how to create the WavyPathText sample slide. Adds viewer.html with
code to animate viewer slides.
This can hopefully be the starting point for future work on bringing
viewer to CanvasKit.
Change-Id: Ia26e08726384b40b3f544fe8254f430dc9db08db
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/278892
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Bug: skia:9935
Change-Id: Idd37e677462fec7ed0beca0fe578fb1a2f497eb8
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/278784
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Previously, the GrAllocator header defined three types: GrAllocator,
GrTAllocator, and GrSTAllocator. GrAllocator was generic, and would
manage the blocks of memory (fixed size to hold N * sizeof(item)). It
stored an SkTArray of pointers to each block. GrTAllocator wrapped
the GrAllocator to add template support for a specific T. GrSTAllocator
extended GrTAllocator to include a template arg for inline storage.
In this CL, GrAllocator is no longer defined, and its memory functionality
is replaced with the use of GrBlockAllocator. For the most part, the
implementation of GrTAllocator on top of GrBlockAllocator remains the
same, although there is explicit array to the block pointers so indexing
is slightly different. GrSTAllocator is also removed entirely, so that
GrTAllocator's template includes initial storage size.
The iteration over the allocated items
is updated to wrap GrBlockAllocator's block iterator, and then iterate
by index within each block. Documentation on GrAllocator already recommended
using the iterator instead of random access, and these changes further
reinforce it. It turns out that many of the use cases of GrAllocator
were written to use random access, so many of the files outside of
GrAllocator.h have just been updated to use the new for-range iteration
instead of a random access for loop.
Change-Id: I28b0bc277c323fd7035d4a8442ae67f058b2b64c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/272058
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Chris Dalton <csmartdalton@google.com>
Some may not want to always compile XPS on Windows
Change-Id: Icd4cc993667fdce740216b9c52a0a649dcf79645
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/278782
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Properly tagging links in PDFs just required a small change: at the time
an annotation is drawn, we need to keep track of the bounding rect, the
url and/or named destination, and now additionally the node ID. Instead
of keeping track of separate maps of rects/urls and rects/dests, this
patch combines them into a vector of SkPDFLinks.
Then, at the time the annotation is written to the file, an object
reference to that annotation can be saved and passed to the document
structure tree, where it can be included as an additional child of
the node with that node ID.
That allows for properly tagging the link and optionally giving it alt
text (like for an image link).
Bug: chromium:1039816
Change-Id: I97e47d3c70949020c3e0a69b8c9fc743748f3a7b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/277426
Commit-Queue: Dominic Mazzoni <dmazzoni@chromium.org>
Reviewed-by: Ben Wagner <bungeman@google.com>
This doesn't do much except creates the new class.
Change-Id: I157abaddd173bf1b6ab5eba2539e90c4d530a273
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/278469
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
Add GrD3DTextureInfo and GrD3DBackendSurfaceInfo, and uses those
to initialize GrBackendTexture and GrBackendRendertarget.
Bug: skia:9935
Change-Id: I4571c1b3aa8115250ff748deb8cf4a95f80f1237
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/278036
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Updated to use sentinel GL context even when GL backend is not built.
This reverts commit 1171d314ef.
Change-Id: Ia94bbe4865ddd4e898446c13886877c539f0eb0b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/277976
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
On certain older versions of the Clang toolchain, the use of the API_AVAILABLE
macro on symbols in C++ translation units causes the visibility of those
symbols to me treated as default instead of the hidden. This causes internal
symbols to be exposed from release dylibs.
This mechanism allows users of the toolchains that have not been updated to the
latest versions to disable the use of the macro in release configurations.
Change-Id: I656361770c2011cff4c1b252761b5d0f3d89edc5
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/277775
Auto-Submit: Chinmay Garde <chinmaygarde@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
We haven't tested this in a while. Use the Metal backend instead.
Change-Id: Ic06bf4faff99950bd24e41bdea03962db99cfeee
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/277612
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Jim Van Verth <jvanverth@google.com>
SK_SUPPORT_LEGACY_ONDRAWBITMAP_VIRTUALS flag to stage this
Change-Id: I32c1bc954446b44cbe656f07cf6f2ad70668b723
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/277736
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Reed <reed@google.com>
This had a not-very-useful matrix utility in it. We've had setSkMatrix
for a while, and the one other user always wanted a 4x4, which can be
done with SkM44 just as easily.
Change-Id: I3f00a0a1ccaf58bc9c775da4eef819af5a5fa7e8
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/277605
Commit-Queue: Brian Salomon <bsalomon@google.com>
Auto-Submit: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
This moves the byte block linked list structure outside of GrMemoryPool
into a new type, GrBlockAllocator. This new type is solely responsible
for managing the byte blocks, tracking where the next allocation
occurs, and creating/destroying the byte blocks. It also tries to
encapsulate all of/most alignment related math, while making it
convenient for clients to add per-allocation padding/metadata.
It has added functionality compared to the original block linked list
that was embedded in GrMemoryPool:
- Supports resetting the entire allocator
- Supports resizing the last allocation
- Is able to rewind an entire stack of allocations, instead of just the
last allocation.
- Supports multiple block growth policies instead of just a fixed size.
- Supports templated alignment, and variable alignment within a single
GrBlockAllocator
- Query the amount of available memory
- Performs as much math as possible in 32-bit ints with static asserts
that ensure overflow won't happen.
Some of this flexibility was added so that the GrBlockAllocator can be
used to implement an arena allocator similar to SkArenaAlloc, or to
replace the use of SkTArray in GrQuadBuffer. It is also likely possible
that GrAllocator can be written on top of GrBlockAllocator. I will try
to perform these consolidations in later CLs.
Change-Id: Ia6c8709642369b66b88eb1bc46264fb2aa9b62ab
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/262216
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
In the old code, the cache was checked and perged on every reattach
of a strike. That was left out of the multi-threaded code. Add the
check and purge back in to maintain cache size.
* Removed minimum cache size from setCacheSizeLimit.
Bug: skia:10046
Change-Id: I2438c83f04b6da8133c161a29604c3c3d7f58cd8
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/277066
Commit-Queue: Herb Derby <herb@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
The only vaguely tricky thing to adapt from templating on T to T*.
Don't think there's a need for the unit tests now right?
Bug: skia:9703
Change-Id: Ib8fcebd9e0e35bea5ef23e6fd5962654a28d587b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/277214
Auto-Submit: Mike Klein <mtklein@google.com>
Commit-Queue: Herb Derby <herb@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Seems very one-off (esp. given SkSL). No one seems to use it.
Change-Id: Iaded54c5b4183fa4aa9c318b5dbe1d410cca539a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/276617
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Reed <reed@google.com>
