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
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
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
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
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
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
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
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
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
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
Review URL: https://codereview.chromium.org/1061783002
For some reason, GM's are now being composited against white
in some modes, where the alpha used to be ignored (or composited
against black, I'm not sure which). At any rate, it doesn't
make much sense to have alpha in the result anyway, so let's clear to
opaque black instead of transparent black and avoid the problem.
This is a trial balloon for bitmapsource and pictureimagefilter.
If all goes well, I'll make this change more widely.
R=scroggo
BUG=skia:3319
Review URL: https://codereview.chromium.org/1074513002
