If no one has read the picture's unique ID, there's no point invalidating it.
This is the same trick we pull with SkPixelRefs.
Before:
26M 1 1.49µs 1.6µs 1.77µs 6.25µs 42% picture_overhead_draw
13M 32 742ns 749ns 756ns 823ns 2% picture_overhead_nodraw
After:
26M 1 1.27µs 1.33µs 1.49µs 5.51µs 45% picture_overhead_draw
14M 43 677ns 680ns 681ns 701ns 1% picture_overhead_nodraw
BUG=skia:
Review URL: https://codereview.chromium.org/1061283002
Reason for revert:
This appears to be breaking large text on Nexus 7.
Original issue's description:
> Calculate inverse scale for distance field text in vertex shader
>
> This is for the uniform scale case only. Using the dFdx() function on certain
> Mali GPUs causes issues because the precision is too low, so we have to
> compute 1/scale from the view matrix instead.
>
> BUG=skia:3528
>
> Committed: https://skia.googlesource.com/skia/+/5b143038cb47763974d2750ed78d436eb6c38beaTBR=bsalomon@google.com,joshualitt@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:3528
Review URL: https://codereview.chromium.org/1066613003
This is for the uniform scale case only. Using the dFdx() function on certain
Mali GPUs causes issues because the precision is too low, so we have to
compute 1/scale from the view matrix instead.
BUG=skia:3528
Review URL: https://codereview.chromium.org/1029423003
This is the same clamp we do in onCreateTexture() for Skia-native textures.
Without this fix, setting to a count higher than the max in Chrome results
in a black screen.
BUG=skia:
Review URL: https://codereview.chromium.org/1056253003
- It's no longer needed to help the (2011?) transition to SkAutoTUnref.
- It prevents us from making classes that go in SkAutoTUnrefs final,
i.e. all ref-counted classes.
This had better not have been public API...
TBR=reed@google.com
BUG=skia:
Review URL: https://codereview.chromium.org/1068443002
The file is expected to contain a list of strings. If the hash for
any result is in this file, don't write an image for it.
BUG=skia:3521
Review URL: https://codereview.chromium.org/1059363002
All platforms except android are configured to use the statically linked copy
of libpng. Android uses the system provided dynamic copy for SkImageDecoder
and the static copy for SkCodec. The exception being android framework builds
that currently use the dynamic copy everywhere.
This CL also enables NEON optimizations for libpng.
Review URL: https://codereview.chromium.org/1058823002
SkCodec::NewFromStream claims to delete the passed in SkStream on
failure. This allows the caller to pass an SkStream to the function
and not worry about deleting it depending on the return value.
Most of our SkCodecs did not honor this contract though. Update them
to delete the stream on failure. Further, update SkCodec::NewFromStream
to delete the stream if it did not match any subclass, and delete the
SkCodec if we decided to return NULL because it was too big.
Add a test which tests streams which represent the beginnings of
supported format types but do not contain enough data to create an
SkCodec. The interesting part of the test is when we run it on ASAN,
which will report that we leaked something without the other changes.
BUG=skia:3257
Review URL: https://codereview.chromium.org/1058873006
The colorfilter is applied to a single (paint's) color, so the bench does not
measure the filter at all, but simply the blit of a color.
BUG=skia:
TBR=
Review URL: https://codereview.chromium.org/1055383002
It's looking like the previous CL did not fix the Daisy bot GMs,
even though that's still the only bit of code I can find that was
ignoring color order. Puzzled. Reverting arm_version=7 for now.
BUG=skia:1843
Review URL: https://codereview.chromium.org/1051423002
Add a virtual method on SkStream which will do a "peek" some bytes, so
that those bytes are read, but the next call to read will be
unaffected.
Implement peek for SkMemoryStream, where the implementation is simple
and obvious.
Implement peek on SkFrontBufferedStream.
Add tests.
Motivated by decoding streams which cannot be rewound.
TBR=reed@google.com
BUG=skia:3257
Review URL: https://codereview.chromium.org/1044953002
I don't see any color-order handling logic in the 32-bit code.
BUG=skia:1843
CQ_EXCLUDE_TRYBOTS=client.skia.compile:Build-Win-MSVC-x86-Debug-Trybot,Build-Win-MSVC-x86_64-Debug-Trybot
R=mtklein@google.com
Review URL: https://codereview.chromium.org/1051683003
This font contains two glyphs, one for 'a' and one for 'A'. The em size
is 128, and the 'a' fits in this. The big 'A', however, is ~3000 in
in each direction.
Review URL: https://codereview.chromium.org/1016153002
Each of these conversion functions now only asserts is output is valid.
For SkPMColor -> SkPMFloat, we assert isValid().
For SkPMFloat -> SkPMColor, we SkPMColorAssert.
#floats
BUG=skia:
BUG=skia:3592
Review URL: https://codereview.chromium.org/1055093002
