| Commit message (Collapse) | Author | Age |
|
|
|
| |
Review URL: https://codereview.chromium.org/1072933004
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/1076593002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As used today, SkNi is used in bool-y contexts. This keeps that, but under a
new name, SkNb. This makes room for a new SkNi that's focused on integer-y
things like loads, stores, arithmetic, etc.
The main reason to split these is that we want different specializations for
each use case: for bools, it's important for us to specialize 32- and 64-bit to
support efficient float- and double- comparisons, but for integer work we're
more likely to be looking at 8- and 16- bit lanes. Keeping these use cases
siloed helps me manage the compexity of the backend NEON and SSE code.
BUG=skia:
Review URL: https://codereview.chromium.org/1083123002
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/1085883002
|
|
|
|
|
|
| |
BUG=skia:3723
Review URL: https://codereview.chromium.org/1083663006
|
|
|
|
|
|
|
|
| |
High quality anisotropic is an interesting edge case for the gpu backend. For scales that are both minimizing and maximizing Ganesh falls back to MipMaps which can turn out too blurry.
BUG=472864
Review URL: https://codereview.chromium.org/1058133003
|
|
|
|
|
|
| |
BUG=470083
Review URL: https://codereview.chromium.org/1081173002
|
|
|
|
|
|
|
|
|
| |
Don't assert if resources are missing
R=scroggo@google.com
BUG=skia:3719
Review URL: https://codereview.chromium.org/1080073002
|
|
|
|
|
|
|
|
| |
Disabling scanline decoding to kIndex8 until it can be implemented.
BUG=skia:3715
Review URL: https://codereview.chromium.org/1082923002
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This also contains a fix to remove recursion from the sorted_merge()
step. This was essentially tail-recursion, and was causing stack
exhaustion on some platforms. Making it iterative fixes the issue.
Note: this CL will affect a large number of GPU GM results.
R=bsalomon@google.com
BUG=
Review URL: https://codereview.chromium.org/1080113004
|
|
|
|
|
|
| |
BUG=skia:3506
Review URL: https://codereview.chromium.org/1056763004
|
|
|
|
|
|
| |
BUG=skia:3686
Review URL: https://codereview.chromium.org/1048333003
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When an SkRecord has more than kInlineRecords ops in it (today, 5 or more), the
current logic undercounts the bytes used by the SkRecord by sizeof(Record) *
kInlineRecords, i.e. 32 bytes. This isn't a huge deal... by the time you've
recorded 5 ops, we're typically up around 1KB anyway, and it's only ever off by
that constant 32 bytes, so somewhere between 3% to 0% error as the picture grows.
But now that I've noticed, we might as well fix it. Basically, this is a
reminder that the inline space used to store those first kInlineRecords ops
goes to waste once we pass that threshold. In contrast, fInlineAlloc, the
space we preallocate for the SkVarAlloc, never goes to waste. It always holds
the first few ops' data even when we grow past it.
BUG=skia:
Review URL: https://codereview.chromium.org/1081433002
|
|
|
|
|
|
|
| |
BUG=skia:
TBR=
Review URL: https://codereview.chromium.org/1087583002
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/1082783002
|
|
|
|
|
|
|
| |
R=mtklein@google.com
BUG=skia:3654
Review URL: https://codereview.chromium.org/1082753002
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit c185019d009dbfcc8d07f267b0fd72ba1ce673d9.
Reason for revert: Causing errors in DM runs.
BUG=skia:
TBR=bsalomon@google.com
Review URL: https://codereview.chromium.org/1087563002
|
|
|
|
|
|
|
|
|
| |
Note: this will affect a large number of GPU GM results.
R=bsalomon@google.com
BUG=
Review URL: https://codereview.chromium.org/1084573003
|
|
|
|
|
|
|
| |
NOTRY=true
DOCS_PREVIEW= https://skia.org/?cl=1084583002
Review URL: https://codereview.chromium.org/1084583002
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/1065293003
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/1062863002
|
|
|
|
|
|
|
|
|
|
| |
10% speedup for clipped haircubics
BUG=skia:
TBR=
NOTRY=True
Review URL: https://codereview.chromium.org/1079343002
|
|
|
|
|
|
|
| |
BUG=skia:
TBR=
Review URL: https://codereview.chromium.org/1085453002
|
|
|
|
|
|
|
| |
BUG=skia:
TBR=
Review URL: https://codereview.chromium.org/1079813002
|
|
|
|
|
|
|
| |
BUG=skia:
TBR=
Review URL: https://codereview.chromium.org/1077353002
|
|
|
|
|
|
|
|
|
| |
precursor for https://codereview.chromium.org/1074313002/
BUG=skia:
TBR=
Review URL: https://codereview.chromium.org/1084433002
|
|
|
|
|
|
|
|
|
|
|
| |
Calling CGFontCopyTableForTag did not affect the runtime results,
so try to actually access the data to see if that makes a
difference.
TBR=reed1
This is a test change, allow data to be collected.
Review URL: https://codereview.chromium.org/1076183004
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The bmp codec currently returns kIncompleteInput
when the stream is truncated, which we treat as a
partial success. However, we neglect the fill the
remaining pixels in the image, leaving these
uninitialized.
This CL addresses this problem by initializing the
remaining pixels in the image to default values.
BUG=skia:3257
Review URL: https://codereview.chromium.org/1075243003
|
|
|
|
|
|
| |
Missed this in https://codereview.chromium.org/1072603002/ (Add GM to repro crbug.com/472795)
Review URL: https://codereview.chromium.org/1078113002
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/1076193003
|
|
|
|
|
|
|
|
|
| |
entire budget can be used up, but it will not be able to free up any space due to blobs being stuck in the GrInOrderDrawBuffer. This was causing a segfault. After this CL the cache will try to purge, and then flush if it cannot purge enough. It will not purge the most recent addition to the cache.
TBR=bsalomon@google.com
BUG=skia:
Review URL: https://codereview.chromium.org/1071333002
|
|
|
|
|
|
|
|
|
|
|
| |
According to bench/MemsetBench.cpp, I've got them somewhere between 10% slower
and a percent or two faster than the old assembly.
BUG=skia:
CQ_EXTRA_TRYBOTS=client.skia.android:Test-Android-GCC-Nexus5-CPU-NEON-Arm7-Debug-Trybot
Review URL: https://codereview.chromium.org/1075003002
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/1067853002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The benches for N <= 10 get around 2x faster on my N7 and N9. I believe this
is because of the reduced function-call-then-function-pointer-call overhead on
the N7, and additionally because it seems autovectorization beats our NEON code
for small N on the N9.
My desktop is unchanged, though that's probably because N=10 lies well within a
region where memset's performance is essentially constant: N=100 takes only
about 2x as long as N=1 and N=10, which perform nearly identically.
BUG=skia:
Review URL: https://codereview.chromium.org/1073863002
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/1078843002
|
|
|
|
|
|
|
|
|
| |
Motivation: Having a class here was unnecessary, since the only thing
that set this class apart was how it is created, not how it behaves.
BUG=skia:3585
Review URL: https://codereview.chromium.org/1068343003
|
|
|
|
|
|
|
|
| |
BUG=skia:
TBR=
Review URL: https://codereview.chromium.org/1072183002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We may want to enable swizzles to 565
for images that are encoded in a format
similar to 565, however, we do not want
to take images that decode naturally to
kN32 and then convert them to 565.
***Enable swizzles to kIndex_8. For images
encoded in a color table format, we suggest
that they be decoded to kIndex_8. When we
decode, we only allow conversion to kIndex_8
if it matches the suggested color type (except
wbmp which seems good as is).
***Modify dm to test images that decode to
kIndex_8.
BUG=skia:3257
BUG=skia:3440
Review URL: https://codereview.chromium.org/1055743003
|
|
|
|
|
|
|
|
| |
N.B.: this will change results on the bots for all the tests modified.
BUG=skia:3319
Review URL: https://codereview.chromium.org/1077763002
|
|
|
|
|
|
|
|
|
|
| |
Some back ends may crash when asked to draw an empty bitmap, so we
filter it out here.
BUG=skia:3692
R=djsollen@google.com,reed@google.com
Review URL: https://codereview.chromium.org/1072033002
|
|
|
|
|
|
|
|
|
|
|
| |
Step 1 of a zillion in the quest for NEON on iOS,
and step 1 of a different zillion in the Great Assembly Purge.
ios, arm, arm64, arm_v7, arm_v7_neon all build.
BUG=skia:
Review URL: https://codereview.chromium.org/1072063002
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of using a full-blown SkPaint to store run font info, use a
custom structure.
This saves 96 bytes / run on 64bit platforms.
R=reed@google.com,mtklein@google.com,joshualitt@google.com
Review URL: https://codereview.chromium.org/1070943002
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/1069463002
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/1076853002
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/1073473005
|
|
|
|
| |
Review URL: https://codereview.chromium.org/1054073003
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This rearranges the record pointers and types so they can go in a single array, then preallocates some space for them and for the SkVarAlloc.
picture_overhead_draw bench drops from ~1000ns to 500-600ns, with no effect on picture_overhead_nodraw.
I don't see any significant effect on large picture recording times from our .skps.
BUG=chromium:470553
Committed: https://skia.googlesource.com/skia/+/e2dd9408cd711777afaa9410427fb0d761ab004a
Review URL: https://codereview.chromium.org/1061783002
|
|
|
|
|
|
| |
BUG=skia:3689
Review URL: https://codereview.chromium.org/1077673002
|
|
|
|
|
|
|
|
| |
This CL also adds a new parameter to SkBitmapSource which gives the user control of the filter quality.
BUG=472795
Review URL: https://codereview.chromium.org/1072603002
|
|
|
|
|
|
|
|
|
|
|
| |
No longer used in Chromium.
Also drop now-unused SkMatrix::Rot_pts() & SkMatrix::RotTrans_pts().
BUG=475022
R=reed@google.com,mtklein@google.com
Review URL: https://codereview.chromium.org/1071833002
|