This is essential for representing non-lutAtoBType A2B tags such as
lut16Type, lut8Type, mpet. Parsing of A2B0 tags was also moved ahead
of the TRC/XYZ-matrix parsing, as profiles examined with both tags
either had the TRC/XYZ tags as a fall-back or were incorrectly displayed
if only the TRC/XYZ tags were used.
This was submitted alone to reduce CL size. Tests that will use these changes will be introduced in the subsequent CLs that add on lut8/16Type A2B0 parsing. We already have lut16Type test images and these have been tested locally, but require additional code not submitted yet for lut16Type ICC profile parsing and A2B colorspace xforms.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2444553002
Review-Url: https://codereview.chromium.org/2444553002
This doesn't print a backtrace, but it's better than nothing.
By preserving the original signal handler and calling into that, we keep the Android system stack trace, visible in logcat, the "dump log" step on bots.
Tested locally on Mac and Android by making an arbitrary GM segfault.
BUG=skia:5876
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3860
Change-Id: Ia7a962ca50e09d370423a6106033e34c47d7643d
Reviewed-on: https://skia-review.googlesource.com/3860
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
There appear to be no existing overriders of the refAs.. method outside
Skia.
Change-Id: Iab174e83023093b4d7fc0bd8907666b66ddb1eea
Reviewed-on: https://skia-review.googlesource.com/3746
Reviewed-by: Ben Wagner <benjaminwagner@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
Add an interface to decode frames beyond the first in SkCodec, and
add an implementation for SkGifCodec.
Add getFrameData to SkCodec. This method reads ahead in the stream
to return a vector containing meta data about each frame in the image.
This is not required in order to decode frames beyond the first, but
it allows a client to learn extra information:
- how long the frame should be displayed
- whether a frame should be blended with a prior frame, allowing the
client to provide the prior frame to speed up decoding
Add a new fields to SkCodec::Options:
- fFrameIndex
- fHasPriorFrame
The API is designed so that SkCodec never caches frames. If a
client wants a frame beyond the first, they specify the frame in
Options.fFrameIndex. If the client does not have the
frame's required frame (the frame that this frame must be blended on
top of) cached, they pass false for
Options.fHasPriorFrame. Unless the frame is
independent, the codec will then recursively decode all frames
necessary to decode fFrameIndex. If the client has the required frame
cached, they can put it in the dst they pass to the codec, and the
codec will only draw fFrameIndex onto it.
Replace SkGifCodec's scanline decoding support with progressive
decoding, and update the tests accordingly.
Implement new APIs in SkGifCodec. Instead of using gif_lib, use
GIFImageReader, imported from Chromium (along with its copyright
headers) with the following changes:
- SkGifCodec is now the client
- Replace blink types
- Combine GIFColorMap::buildTable and ::getTable into a method that
creates and returns an SkColorTable
- Input comes from an SkStream, instead of a SegmentReader. Add
SkStreamBuffer, which buffers the (potentially partial) stream in
order to decode progressively.
(FIXME: This requires copying data that previously was read directly
from the SegmentReader. Does this hurt performance? If so, can we
fix it?)
- Remove UMA code
- Instead of reporting screen width and height to the client, allow the
client to query for it
- Fail earlier if the first frame AND screen have size of zero
- Compute required previous frame when adding a new one
- Move GIFParseQuery from GIFImageDecoder to GIFImageReader
- Allow parsing up to a specific frame (to skip parsing the rest of the
stream if a client only wants the first frame)
- Compute whether the first frame has alpha and supports index 8, to
create the SkImageInfo. This happens before reporting that the size
has been decoded.
Add GIFImageDecoder::haveDecodedRow to SkGifCodec, imported from
Chromium (along with its copyright header), with the following changes:
- Add support for sampling
- Use the swizzler
- Keep track of the rows decoded
- Do *not* keep track of whether we've seen alpha
Remove SkCodec::kOutOfOrder_SkScanlineOrder, which was only used by GIF
scanline decoding.
Call onRewind even if there is no stream (SkGifCodec needs to clear its
decoded state so it will decode from the beginning).
Add a method to SkSwizzler to access the offset into the dst, taking
subsetting into account.
Add a GM that animates a GIF.
Add tests for the new APIs.
*** Behavior changes:
* Previously, we reported that an image with a subset frame and no transparent
index was opaque and used the background index (if present) to fill the
background. This is necessary in order to support index 8, but it does not
match viewers/browsers I have seen. Examples:
- Chromium and Gimp render the background transparent
- Firefox, Safari, Linux Image Viewer, Safari Preview clip to the frame (for
a single frame image)
This CL matches Chromium's behavior and renders the background transparent.
This allows us to have consistent behavior across products and simplifies
the code (relative to what we would have to do to continue the old behavior
on Android). It also means that we will no longer support index 8 for some
GIFs.
* Stop checking for GIFSTAMP - all GIFs should be either 89a or 87a.
This matches Chromium. I suspect that bugs would have been reported if valid
GIFs started with "GIFVER" instead of "GIF89a" or "GIF87a" (but did not decode
in Chromium).
*** Future work not included in this CL:
* Move some checks out of haveDecodedRow, since they are the same for the
entire frame e.g.
- intersecting the frameRect with the full image size
- whether there is a color table
* Change when we write transparent pixels
- In some cases, Chromium deemed this unnecessary, but I suspect it is slower
than the fallback case. There will continue to be cases where we should
*not* write them, but for e.g. the first pass where we have already
cleared to transparent (which we may also be able to skip) writing the
transparent pixels will not make anything incorrect.
* Report color type and alpha type per frame
- Depending on alpha values, disposal methods, frame rects, etc, subsequent
frames may have different properties than the first.
* Skip copies of the encoded data
- We copy the encoded data in case the stream is one that cannot be rewound,
so we can parse and then decode (possibly not immediately). For some input
streams, this is unnecessary.
- I was concerned this cause a performance regression, but on average the
new code is faster than the old for the images I tested [1].
- It may cause a performance regression for Chromium, though, where we can
always move back in the stream, so this should be addressed.
Design doc:
https://docs.google.com/a/google.com/document/d/12Qhf9T92MWfdWujQwCIjhCO3sw6pTJB5pJBwDM1T7Kc/
[1] https://docs.google.com/a/google.com/spreadsheets/d/19V-t9BfbFw5eiwBTKA1qOBkZbchjlTC5EIz6HFy-6RI/
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=2045293002
Review-Url: https://codereview.chromium.org/2045293002
This test has nearly coincident lines that are missorted.
The underlying bug is caused when a pair of curves
are coincident when reduced to line segments, but the
end points aren't detected.
The error was generated by running nanobench over all svg
sample data with the distance field patch installed.
TBR=reed@google.com
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2440043003
Review-Url: https://codereview.chromium.org/2440043003
Matches our naming convention for all other types - factories that
return sk_sp (or any type that intelligently manages its own
lifetime) are named Make.
Previous factories are still around, assuming
SK_SUPPORT_LEGACY_COLOR_SPACE_FACTORIES is defined. Enable that
define for Android, etc.
See also: https://codereview.chromium.org/2442053002/
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3822
Change-Id: Iaea9376490736b494e8ffc820831f052bbe1478d
Reviewed-on: https://skia-review.googlesource.com/3822
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Reed <reed@google.com>
These versions will eliminate lots of copy-pasting in various fragment
processor creation code.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3787
Change-Id: I3ada2d4866e92cfc0507beeea11e05790d73757d
Reviewed-on: https://skia-review.googlesource.com/3787
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
I believe that the complaints are occurring because the |a| vector
might be uninitialized where it is used here. It doesn't actually
matter because we won't use or store that value - it's just a
placeholder.
But we need to make the bot happy.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3800
Change-Id: I1891da9d1d2708008e4606daebf9bb6f96e92fc0
Reviewed-on: https://skia-review.googlesource.com/3800
Commit-Queue: Matt Sarett <msarett@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
In clamp mode, we use a couple of synthetic edges that are supposed to
extend to +/- infinity (-inf .. P0 and Pn .. inf). Currently we use
SK_ScalarMin/Max, but these can be overrun with large/malicious inputs.
Use SK_ScalarInfinity/SK_ScalarNegativeInfinity instead, and tweak
compute_interval_props() to handle inf values gracefully.
BUG=skia:5835
R=reed@google.com
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2441733002
Review-Url: https://chromiumcodereview.appspot.com/2441733002
MSAN and the no-SIMD bots have noticed the top lanes of the tail vectors are not initialized.
As they were written it was faster to leave them unintialized, but as re-written here it's equal speed and now safe.
CQ_INCLUDE_TRYBOTS=master.client.skia:Perf-Ubuntu-Clang-GCE-CPU-AVX2-x86_64-Debug-MSAN-Trybot,Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3790
Change-Id: Icd41ba14ae6baf9947eb361a366f1ce19ad8aa67
Reviewed-on: https://skia-review.googlesource.com/3790
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
This may work around an Chrome/MSVC/PGO compiler crasher.
Even if not, it's harmless for performance, and arguably more readable.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3789
Change-Id: I0bf23f65d7832b9f43e275f85e7985fcd6b13b9f
Reviewed-on: https://skia-review.googlesource.com/3789
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Mike Klein <mtklein@chromium.org>
CQ_INCLUDE_TRYBOTS=master.client.skia:Test-Ubuntu-Clang-GCE-CPU-AVX2-x86_64-Debug-ASAN-Trybot;master.client.skia:Test-Ubuntu-Clang-GCE-CPU-AVX2-x86_64-Debug-MSAN-Trybot
Change-Id: I27a714388b8ded7dfc968e322b0a587205f575f1
Reviewed-on: https://skia-review.googlesource.com/3731
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Ben Wagner <bungeman@google.com>
We don't call the tail code nearly as often as the body code, but when we do and call memcpy(), we first have to vzeroupper back into the non-AVX world. That does seem to slow things down considerably. You wouldn't think it, but this gives a nice speed up (tested on Windows).
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3783
Change-Id: I40cbe1e529f2431825edec7638265601b64e7ec5
Reviewed-on: https://skia-review.googlesource.com/3783
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Even with a modest cache, we're going to get nearly 100% hit rate
for typical usage scenarios. I'm hoping to avoid the special case
caching of sRGB -> destination, and just rely on the more general
mechanism.
Yes, this is yet-another cache class. I wanted to use one of many
that are laying around, but couldn't find a good fit. On the plus
side, it's not much code.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3726
Change-Id: I943be5c99f0d691a87ffe8c5bc3067a8eb491fc2
Reviewed-on: https://skia-review.googlesource.com/3726
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Also going to use this to allow caching of GrColorSpaceXforms
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3670
Change-Id: I56ed2dcbdddc22046263f56d68f2d6aea55547c8
Reviewed-on: https://skia-review.googlesource.com/3670
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Matt Sarett <msarett@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
I'm seeing /GS's _security_check_cookie() show up as a signficant piece of time when profiling. That's mostly just annoying noise. We generally use our Release builds for performance testing and Debug for correctness, so it seems like a fair thing to disable in Release builds... it's a sort of ASAN thing, which we only do in Debug on other platforms.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3782
Change-Id: I9b3cf4c5cf943fc2549f5bf91a1f6f7e41733e2c
Reviewed-on: https://skia-review.googlesource.com/3782
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Ben Wagner <bungeman@google.com>
These two together shave another 5MB off dm.exe, from 16MB -> 11MB.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3738
Change-Id: Id216867e0ad5bc115fbd4006095860dff9204947
Reviewed-on: https://skia-review.googlesource.com/3738
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Ben Wagner <bungeman@google.com>
By default, MSVC generates standalone versions of all functions, including static inline functions that are only inlined. Those standalone versions are dead code. This /Zc:inline flag makes MSVC behave like all the other compilers, omitting those standalone functions. Chrome builds with this flag.
This CL cuts dm.exe and nanobench.exe each down by about 3MB, 19->16MB for DM and 15MB->12MB for nanobench. This shouldn't affect runtime speed, and didn't signficantly change clean build time on my Z840 (~90s either way).
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3735
Change-Id: Ibd2a80337fcefc3f4eaf4335ea4e95a80bb4fddb
Reviewed-on: https://skia-review.googlesource.com/3735
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Ben Wagner <bungeman@google.com>
(1) The transformation code *should* support any src SkColorSpace
that we successfully parse. This is agreed upon internally and
by clients. The fact that we currently don't is just a bug...
(2) We cannot and will not support all SkColorSpaces as dsts.
So if we fail to make a SkColorSpaceXform, we should assume that
it was caused by a bad dst color space. The correct response in
this case is to return kInvalidConversion. I've rewritten the CL
to do this.
The fact that weird src spaces will sometimes trigger a
kInvalidConversion is just a bug that is being actively worked on.
TBR=reed@google.com
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3661
Change-Id: Iac2b45120507ec71b1b3d555c61931f7348dad9e
Reviewed-on: https://skia-review.googlesource.com/3661
Commit-Queue: Matt Sarett <msarett@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
Reviewed-by: Robert Aftias <raftias@google.com>
Unlike -fomit-frame-pointer, this doesn't make debugging or profiling any more difficult, as it only applies to leaves. It will make our code (negligibly) smaller and (negligibly) faster.
Mostly I just find it easier to read the disassembly without all the rbp gymnastics getting in the way.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3700
Change-Id: I4b96aee7619791d5980de7f46e82836ca08a6456
Reviewed-on: https://skia-review.googlesource.com/3700
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
- Give body and tail functions separate types. This frees a register in body functions, especially important for Windows.
- Fill out default, SSE4.1, and HSW versions of all functions. This means we don't have to mess around with SkNf_abi... all functions come from the same compilation unit where SkNf is a single consistent type.
- Move Stage::next() into SkRasterPipeline_opts.h as a static inline function.
- Remove Stage::ctx() entirely... fCtx is literally the same thing.
This is a step along the way toward building the entire pipeline in src/opts, removing the need for all the stages to be functions living in SkOpts.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3680
CQ_INCLUDE_TRYBOTS=master.client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot,Test-Ubuntu-Clang-GCE-CPU-AVX2-x86_64-Debug-ASAN-Trybot
Change-Id: I7de78ffebc15b9bad4eda187c9f50369cd7e5e42
Reviewed-on: https://skia-review.googlesource.com/3680
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
