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
No diffs against head for DM --config 8888 gpu 2ndpic-8888 2ndpic-gpu.
picture_overhead_draw 1.62us -> 1.6us 0.99x
picture_overhead_nodraw 792ns -> 342ns 0.43x
tiles and serialization modes will also test this a bit.
BUG=chromium:470553
Review URL: https://codereview.chromium.org/1067893002
approx-match.
This revealed some further 0..1 texture coordinate
depedencies,specifically in SkDisplacementMapEffect and
SkXfermodeImageFilter, fixed through use of
GrTextureDomain.
Note: causes minor pixel diffs in pictureimagefilter,
testimagefilters GMs.
Also causes minor pixel diffs in some Blink layout tests,
suppressed here: https://codereview.chromium.org/1064943002
BUG=skia:3532
Review URL: https://codereview.chromium.org/1065683002
Since wide strings are only used in SkPDFDevice, I have moved the
function that manages them to that directory.
Motivation: The SkPDFString will be refactored later along with the
other SkPFObject heirarchy.
BUG=skia:3585
Review URL: https://codereview.chromium.org/1064013003
I'm going to start hacking on SkCanvas a bit to allow a fast reset method,
and I want to have some testing checking me.
BUG=skia:
Review URL: https://codereview.chromium.org/1062043004
