Change-Id: I4b1a2a9c89db59a6a1674388f9ab220a2ec9a61c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/258656
Commit-Queue: Herb Derby <herb@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
Auto-Submit: Herb Derby <herb@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
SkFont::countText returns -1 to let the user know that the text was not
valid in the encoding specified. Users need to check for this and act
appropriately. Otherwise in debug and assert will probably fire and in
release unexpected things may happen.
Change-Id: I6ce91aa3d978fe5265b659f759b4023b81da261f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/258639
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
Change-Id: I67bd77cf072e203f23ffc49d591cb826fed598dd
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/258640
Commit-Queue: Herb Derby <herb@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
Auto-Submit: Herb Derby <herb@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
Bug: skia:9698
Change-Id: I18d7c65b09c236ed0d23689c71af44e9a0414de8
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/258572
Auto-Submit: Jim Van Verth <jvanverth@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Bug: chromium:985500
Change-Id: Iab73405728dc64c816f736e95b00a23e11fd4888
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/258565
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Change-Id: I7aa85e470343825e6ab21ad210f50c2154f03ad0
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/258570
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Change-Id: Ib6dc1ff861efe4040508fea09c8a66d8d06db597
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/258568
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Previously, a batch draw that reused the same proxy consecutively
would create a ViewCountPair for each set entry, with its count == 1.
This turned into 1 draw per entry, so although there'd still be a single
pipeline, it didn't take advantage of merging those consecutive entries
into a larger draw to reduce draw count as well.
Initially, the thinking for the batch API was that it was for tilers
that used unique images for each tile or render pass. However, Chrome's
compositor is also responsible for rendering 9 patches as part of the UI.
These appear as 9 consecutive entries in the image set that all refer to
the same texture. With this CL the texture op will automatically merge
such occurrences into one ViewCountPair with a count of 9.
The bulkrect_1000_[grid|random]_sharedimage_batch leverages this case.
Before this CL its op would hold 1000 view count pairs that each drew
one quad. Now its op will hold 1 view count pair with a count of 1000.
On my linux workstation, the bulkrect_1000_grid_sharedimage_batch time
went from 377us to 206us. For reference, the _ref variant (which already
was a 1 view count pair with ct == 1000 due to merging of each op) has
a time of 497us. The difference between 497us and 206us represents the
overhead of calling through SkCanvas, op creation, quad optimization
analysis 1000x.
Interestingly the bulkrect_1000_random_sharedimage_batch benchmark did not
change on my workstation. My conjecture is that it is bottlenecked by
overdraw of the many overlapping rectangles.
Change-Id: Icc4195de0bcb2219f424fdaa79728281c0418558
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/258418
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
I should start off with, I don't know this code. I may have
misunderstood what it's trying to do. Is it well tested?
GCC pointed out that using memcpy() with CopyPathRange is a bad idea
since CopyPathRange is non-trivial (has an sk_sp).
Further, this appears to be an archetypical dangerous way to use
memcpy(), because the source and destination alias each other.
Am I understanding it correctly that we want to put the new entry at
fCurrCopyAtlasRangesIdx, sliding everything already past that index over
to make room?
I've tried to replace all this with
1) push_back() to add a slot
2) move_backwards() to slide everything over to the right
3) = {...} to fill in the slot.
Step 2) is a no-op when fCurrCopyAtlasRangesIdx was at the end already.
Then now that we're no longer calling emplace_back, the type
CopyPathRange now no longer needs an explicit constructor.
This is the sort of thing I'm going for here...
~ $ cat test.cc
#include <stdio.h>
#include <vector>
int main(int, char**) {
for (int i = 0; i <= 5; i++) {
std::vector<int> v = {1,2,3,4,5};
v.push_back(0);
std::move_backward(v.begin() + i,
v.end() - 1,
v.end());
v[i] = 42;
for (int x : v) {
printf("%d ", x);
}
printf("\n");
}
return 0;
}
~ $ clang++ test.cc && ./a.out
42 1 2 3 4 5
1 42 2 3 4 5
1 2 42 3 4 5
1 2 3 42 4 5
1 2 3 4 42 5
1 2 3 4 5 42
... which I guess is a roundabout way of spelling "insert()". :P
Change-Id: I0a445aafa9a786ef8044243c7432f8597353a6b5
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/258454
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Chris Dalton <csmartdalton@google.com>
This starts setting up to expose the GrProgramInfos to SkDDL clients.
Bug: skia:9455
Change-Id: Icd89ad88565d13890476463a919bbadcb9210b02
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/256229
Commit-Queue: Robert Phillips <robertphillips@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
Move all the GrTextBlob methods to GrTextBlob.cpp. Under the old API
methods were called once per a glyphs so the methods were colocated
with the painter code. The APIs have changed to bulk, so the colocation
is no longer needed. In addition, the SubRun struct is going to move
from the GrTextBlob to the .cpp, so all these methods need to be together
soon.
Change-Id: I41124be0d5bcca29780be1a7f5c105268dadbe87
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/258566
Commit-Queue: Herb Derby <herb@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
Auto-Submit: Herb Derby <herb@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
This is a first step towards pulling the creation of the GrProgramInfos explicitly into the Ops' onExecute methods. We need this behavior so programInfo creation can be moved forward to onPrePrepare.
For now, pipeline creation is a static member on GrSimpleMeshDrawOpHelper so GrPipeline creation can be bottle-neckedOps for Ops that don't use the helper. In some future world CreatePipeline could become non-static to reduce some of the duplicate code.
Bug: skia:9455
Change-Id: I2d35dd223db824e84616f5df0f1dca34c1b6e412
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/258003
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
GCC gets nervous here, and I think correctly so. The type is
non-trivial (because the linked list has a constructor from its field
initializers) and we're bypassing that instead with a memset(). That'd
be _close_ to fine, but I think less clear than just =
TriangulationVertex{}.
What's really weird is that we're only zeroing it in Debug builds.
Might be we only added this memset() to stop assertions that the node
wasn't already in another linked list?
Anyway, even ignoring all that, this reads a lot more clearly to me.
Change-Id: Iacfe507be2a53807caf85d30f4c4712d8f6e86dc
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/258449
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Prior to this commit, SkWuffsCodec always used what this commit calls
two pass decoding. After this commit, it can sometimes use one pass
decoding, which means we don't have to allocate that intermediate pixel
buffer. For the "droids.gif" example mentioned in a recent commit,
39da10b5 "Optimize SkWuffsCodec pixbuf zero-initialization", this means
that we allocate 19 MB less than we used to (2560 width x 1920 height x
4 bytes per pixel = 19660800 bytes).
Continuing with "droids.gif" and the image_decode_bench program from
39da10b5, the time taken per decode drops from 35.627ms to 28.655ms.
Bug: chromium:1023191
Bug: chromium:1023129
Bug: skia:8235
Change-Id: Ic4fd6bd2856493eaf777416326f39198aa8d97c1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/255956
Commit-Queue: Leon Scroggins <scroggo@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
Change-Id: I96bc057df6b538138827fac7129126381038656a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/258240
Reviewed-by: Ben Wagner aka dogben <benjaminwagner@google.com>
Commit-Queue: Eric Boren <borenet@google.com>
5f857839b9..11e6944ec5
git log 5f857839b9ec..11e6944ec5a8 --date=short --first-parent --format='%ad %ae %s'
2019-12-05 jonahr@google.com Linux AMD crash when src blit region outside framebuffer
2019-12-05 ianelliott@google.com Vulkan: Implement multisample textures
2019-12-05 syoussefi@chromium.org Fix image/sampler uniform range in presence of atomic counters
2019-12-05 syoussefi@chromium.org Fix compute shared memory size validation
2019-12-05 syoussefi@chromium.org Vulkan: EXT_gpu_shader5 support: precise
2019-12-05 jmadill@chromium.org Re-land "Add new test runner harness."
2019-12-05 syoussefi@chromium.org Fix tests checking for major version > 3
2019-12-05 angle-autoroll@skia-public.iam.gserviceaccount.com Roll third_party/glslang/src e58c080d4f02..0de87ee9a5bf (1 commits)
Created with:
gclient setdep -r third_party/externals/angle2@11e6944ec5a8
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/angle-skia-autoroll
Please CC bsalomon@google.com on the revert to ensure that a human
is aware of the problem.
To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md
Cq-Include-Trybots: skia/skia.primary:Build-Debian9-Clang-x86_64-Release-ANGLE;skia/skia.primary:Test-Win10-Clang-AlphaR2-GPU-RadeonR9M470X-x86_64-Debug-All-ANGLE;skia/skia.primary:Test-Win10-Clang-Golo-GPU-QuadroP400-x86_64-Debug-All-ANGLE;skia/skia.primary:Test-Win10-Clang-NUC5i7RYH-GPU-IntelIris6100-x86_64-Debug-All-ANGLE;skia/skia.primary:Test-Win10-Clang-NUC6i5SYK-GPU-IntelIris540-x86_64-Debug-All-ANGLE;skia/skia.primary:Test-Win10-Clang-NUC8i5BEK-GPU-IntelIris655-x86_64-Debug-All-ANGLE;skia/skia.primary:Test-Win10-Clang-NUCD34010WYKH-GPU-IntelHD4400-x86_64-Debug-All-ANGLE
Bug: None
Tbr: bsalomon@google.com
Change-Id: I45f956e54697b9c6ca559f28a8b635b74e6c0335
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/258492
Reviewed-by: skia-autoroll <skia-autoroll@skia-public.iam.gserviceaccount.com>
Commit-Queue: skia-autoroll <skia-autoroll@skia-public.iam.gserviceaccount.com>
... because it has a constructor, implied by all the initializers.
Luckily, that constructor does exactly what our memset() does.
Change-Id: Ibe538e9d840de9e6fd07d673783709df17b7b4fb
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/258447
Commit-Queue: Florin Malita <fmalita@chromium.org>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Normally, we load single-frame images upfront to avoid instantiating
an animator (as the image content is supposed to be constant).
In certain cases, deferred behavior is desirable (and the extra animator
overhead is minimal).
Generalize MultiFrameAnimator to handle single-frame assets, and add an
optional deferred mode for single-frame image loading
(Animation::Builder::Flags::kDeferImageLoading).
Bug: skia:9686
Change-Id: I4d166cd1a0bf34ccb8679e7553848c831a9193d2
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/258000
Commit-Queue: Avinash Parchuri <aparchur@google.com>
Reviewed-by: Avinash Parchuri <aparchur@google.com>
GCC worries we're copying into a union of non-trivial types here, but we
know they're perfectly fine to memcpy() into. We can quiet it down by
casting the destination to void*.
Change-Id: I742bcd264da861998fa1e5b7e8ad70aaafc0805d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/258450
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This is an automated CL created by the recipe roller. This CL rolls recipe
changes from upstream projects (e.g. depot_tools) into downstream projects
(e.g. tools/build).
More info is at https://goo.gl/zkKdpD. Use https://goo.gl/noib3a to file a bug.
recipe_engine:
https://crrev.com/1f2a908debbd1f17a22d1a92f811871e348c7cd6 Update Tricium proto in recipes to contain showOnUnchangedLines field (ltina@google.com)
TBR=borenet@google.com
Recipe-Tryjob-Bypass-Reason: Autoroller
Bugdroid-Send-Email: False
Change-Id: Ifbb442b82c98cdce65b9fc3f6f86219c6794b26a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/258441
Reviewed-by: Recipe Roller <recipe-mega-autoroller@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: Recipe Roller <recipe-mega-autoroller@chops-service-accounts.iam.gserviceaccount.com>
Bug: skia:9556
Change-Id: Ibb0fe82edb9c28efd94cc599856ed9afe71dfd09
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/258416
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
It had been manually std::move()ing without actually
calling it by that name. GCC noticed.
Oh hey, let's call ~T().
Change-Id: Ie54b8906e3a4334f73e46ca9d31dc8542289f238
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/258344
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Change-Id: I36ce78ee1de8096d9aa164444e8af31b3831a3ab
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/258217
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Direct ARGB fallback is only needed when rendering SDFT. So,
the direct mask stage follows the SDFT case to handle any colored
glyphs the SDFT could not handle.
Change-Id: I97dfbcf3177f113402bfa363eef287b2617f3bb4
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/252260
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Herb Derby <herb@google.com>
Just like the first CL, this time hopefully I got all the rest
for SkScalerContextRec. (I had been going file by file...)
Change-Id: Icae83ff0f6f6b360b1f13069c467a40d8f1d8d62
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/258343
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
GCC warns now about memcpy()ing into types that have no trival copy
assignment. (I think it's the mix of public and private fields that
makes SkScalerContextRec non-trivial.)
Yet SkScalarContextRec really is designed for memcpy(), so we can just
stifle it by casting the memcpy() destination pointer to void*.
Change-Id: I72f9aedd3e1ff9d496db066260bcde7178c1bf7a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/258338
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
GCC warngs that we're memcpy()ing into Sk4px, a non-trivial type. We're
really quite sure about its layout (now asserted) so I think it's safe
to just cast to void* to quiet the warnings.
Change-Id: I6b868e0dc7113302914c37b0aac187272203329f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/258270
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
In the DDL-recording world we're now computing GrProgramDescs at record time. This ends up creating the GrSkSLFPFactories involved in multiple threads. As part of the GrContextThreadSafeProxy, the GrSkSLFPFactoryCache has to be thread safe.
This CL also forces GrSkSLFP.h and GrSkSLFPFactoryCache.h to only ever be included in .cpp files.
Bug: skia:9455
Change-Id: Ic5e87c28d2c1c5b468ac81e07b66c1191efbbd65
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/257634
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Bug: skia:
Change-Id: I868da59cfcd4357ea4b2f4018dc3b94bae6d0287
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/258237
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
When deserializing SkRRects we copy the raw data then recreate a little
more analysis stored at the end of the struct that is not serialized.
GCC worries we've not copied enough, but we have. We can stifle the
warning by casting the pointer to void* before calling memcpy().
Change-Id: I3ae0007927611d4fc84ced8d12f62e0fa23ee3ee
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/258267
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
GCC noticed that we're memset()ing fFlags to zero even though
it's non-trivial... non-trivial for having default initializers
that already set all its fields to false. So like, well warned,
but also, the memset() was totally redundant?
Change-Id: I115f41cb5026804ffbb4a0ffacfc9cdb89161d8b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/258266
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Next CL will add call to SkPathPriv::PerspectiveClip() to fix this
Change-Id: Ia52ab019457f363184dc4730ab3e3582669e55e7
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/258242
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Reed <reed@google.com>
../../include/private/SkTArray.h:496:15:
error: ‘void* memcpy(void*, const void*, size_t)’ writing to an object of type
‘class sk_sp<GrTextBlob>’ with no trivial copy-assignment; use copy-assignment
or copy-initialization instead [-Werror=class-memaccess]
memcpy(&fItemArray[dst], &fItemArray[src], sizeof(T));
~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This may be safe in context and the sort of thing we're used to getting
away with, but I think it's probably also the sort of thing we should
try to do as little as possible.
If this is really a major performance choke point, it might make sense
to going back to an array of raw pointers? That's what we had back
before https://skia-review.googlesource.com/c/skia/+/9535/.
Change-Id: If16918f908e8950b81e73b70764bae200bda2e62
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/258265
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Don't implement domains, use child effects instead.
Don't do a 4x4 matrix mul. Do 3x3 + a translate.
Undo some of effects of this effect's stint as .fp generated code.
Specify optimization flags using resulting alpha type.
Multiply computed color with input color (so this is more interchangeable
with GrSimpleTextureEffect used for non-planar texture images)
Change-Id: I9d3d0ff7aed9177cd32ab16e9ceb67d458c3d88c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/257883
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
From here we can start trying it out for real
- skottie could call it directly
- SkDraw could call it for the raster-backend
Change-Id: I703838241d67c539afd3d3e31d0ddf1c66645799
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/258001
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Mike Reed <reed@google.com>
Add Perf testing for Metal on MacBookAir7,2 and MacMini7,1. Also run
Test Debug Metal on MacMini7,1.
Change-Id: Id1a457cd41dda1dee8fc6893e87a6701782b0b2e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/258002
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Auto-Submit: Ben Wagner aka dogben <benjaminwagner@google.com>
Reviewed-by: Jim Van Verth <jvanverth@google.com>
This also now requires that when using a vulkan GrContext, the backing VkDevice,
Queue, and Instance must be alive when the GrContext is first destroyed or
abandoned. Additionally any GrBackendTextures created from the GrContext must
be deleted before destroying or abandoning the GrContext.
Bug: skia:9603
Change-Id: Ibf194d2ffdcddd61e34214d7d59a2d9a33c880e5
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/257921
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
Precomp layers can have a different size vs. main composition.
Instead of relying on the global animation (main comp) size, use the
current (pre)comp size when setting up cameras.
Change-Id: I54106375fb39dde2bfd11e14a38e5ec3e7190764
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/258156
Commit-Queue: Florin Malita <fmalita@chromium.org>
Commit-Queue: Mike Reed <reed@google.com>
Auto-Submit: Florin Malita <fmalita@chromium.org>
Reviewed-by: Mike Reed <reed@google.com>
