I accidentally turned these off in:
https://skia-review.googlesource.com/c/6023/
Even though the decode color type does not match the canvas,
we still want to run the test.
BUG=skia:
Change-Id: Ia96069a44e20d62a58d37a98bac81cfab5470fc0
Reviewed-on: https://skia-review.googlesource.com/6088
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Matt Sarett <msarett@google.com>
Prior to this CL, if a GIF file was truncated before reading the local
color map of a frame, incremental decode would do the wrong thing. In
onStartIncrementalDecode, we would either create a color table based on
the global color map, or we would create a dummy one with only one
color (transparent). The dummy color table is correct if there is
neither a global nor a local color map, and allows us to fill the frame
with transparent. But if more data is provided, and it includes an
actual color map and image data, one of the following can happen:
- If the created color table is smaller than the actual one, the
decoded data may include indices outside of the range of the created
color table, resulting in a crash.
- If we get lucky, and the created color table is large enough, it may
still be the wrong colors (and most likely is).
To solve this, make onStartIncrementalDecode fail if there is a local
color map that has not been read yet. A future call may read more data
and read the correct color map.
This is done by returning kIncompleteInput in
SkGifCodec::prepareToDecode if there is a local color map that has not
yet been read. (It is possible that there is no color map at all, in
which case we still need to support decoding that frame. Skip
attempting to decode in that case.)
In onGetPixels, if prepareToDecode returned kIncompleteInput, return
kInvalidInput. Although the input is technically incomplete, no future
call will provide more data (unlike in incremental decoding), and there
is nothing interesting for the client to draw. This also prevents
SkCodec from attempting to fill the data with an SkSwizzler, which has
not been created. (An alternative solution would be create the dummy
color table and an SkSwizzler, which would keep the current behavior.
But I think the new behavior of returning kInvalidInput makes more
sense.)
Add tests to verify the intended behavior:
- getPixels fails.
- startIncrementalDecode fails, but after providing more data it will
succeed and incremental decoding matches the image decoded from the
full stream.
- Both succeed if there is no color table at all.
Change-Id: Ifb52fe7f723673406a28e80c8805a552f0ac33b6
Reviewed-on: https://skia-review.googlesource.com/5758
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
Currently, just inject the Ganesh context type when running unit tests.
Obviously, we can use this to supply other contextual information around
tests that do many variations of configs, formats, etc...
BUG=skia:
Change-Id: Iab96632a92ec632e4d132bbcc17a91a8dd251e78
Reviewed-on: https://skia-review.googlesource.com/5565
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
BUG=skia:
Change-Id: Id66a68e47f671cafd7c6128787fbd149faf16c7a
Reviewed-on: https://skia-review.googlesource.com/5576
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Changed ICC parsing/SkGammas/SkColorLookUpTable to handle non-3-channel
inputs. Parsed CMYK A2B ICC profiles. Integrated this with SkJpegCodec
(the only file that supports CMYK) and SkColorSpaceXform_A2B to allow
parsing and color xforming of ICC CMYK images.
CQ_INCLUDE_TRYBOTS=skia.primary:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD
Change-Id: I11e3d17180244281be3eb43fd608609925a7f71e
Reviewed-on: https://skia-review.googlesource.com/5444
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Matt Sarett <msarett@google.com>
This reverts commit 51c3fcd376.
Reason for revert: ASAN, MSAN both take issue with parse_and_load_gamma()
Original change's description:
> Added CMYK support for ICC profiles.
>
> Changed ICC parsing/SkGammas/SkColorLookUpTable to handle non-3-channel
> inputs. Parsed CMYK A2B ICC profiles. Integrated this with SkJpegCodec
> (the only file that supports CMYK) and SkColorSpaceXform_A2B to allow
> parsing and color xforming of ICC CMYK images.
>
> BUG=skia:
>
> GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=5197
> CQ_INCLUDE_TRYBOTS=skia.primary:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD
>
>
> Change-Id: Id6619f63f04071f79cd2d84321857dfa269ad3aa
> Reviewed-on: https://skia-review.googlesource.com/5197
> Commit-Queue: Mike Klein <mtklein@chromium.org>
> Reviewed-by: Matt Sarett <msarett@google.com>
> Reviewed-by: Mike Klein <mtklein@chromium.org>
> Reviewed-by: Leon Scroggins <scroggo@google.com>
>
TBR=mtklein@chromium.org,mtklein@google.com,msarett@google.com,scroggo@google.com,brianosman@google.com,raftias@google.com,reviews@skia.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: Ib43fef00bc233c0b4fa47ed29040d69601def267
Reviewed-on: https://skia-review.googlesource.com/5423
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Changed ICC parsing/SkGammas/SkColorLookUpTable to handle non-3-channel
inputs. Parsed CMYK A2B ICC profiles. Integrated this with SkJpegCodec
(the only file that supports CMYK) and SkColorSpaceXform_A2B to allow
parsing and color xforming of ICC CMYK images.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=5197
CQ_INCLUDE_TRYBOTS=skia.primary:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD
Change-Id: Id6619f63f04071f79cd2d84321857dfa269ad3aa
Reviewed-on: https://skia-review.googlesource.com/5197
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Matt Sarett <msarett@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Reviewed-by: Leon Scroggins <scroggo@google.com>
Change-Id: I27b6324f8040899fafeda23ca524bc54a4dbf090
Reviewed-on: https://skia-review.googlesource.com/5392
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
(re-land 248ff02 & 2cb6cb7, with changes)
- Hide SkImageEncoder class in private header.
- SkImageEncoder::Type becomes SkEncodedImageFormat
- SkEncodedFormat becomes SkEncodedImageFormat
- SkImageEncoder static functions replaced with
single function EncodeImage()
- utility wrappers for EncodeImage() are in
sk_tool_utils.h
TODO: remove link-time registration mechanism.
TODO: clean up clients use of API and flip the flag.
TODO: implement EncodeImage() in chromeium/skia/ext
Change-Id: I47d451e50be4d5c6c130869c7fa7c2857243d9f0
Reviewed-on: https://skia-review.googlesource.com/4909
Reviewed-by: Mike Reed <reed@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
Reviewed-on: https://skia-review.googlesource.com/5186
Commit-Queue: Hal Canary <halcanary@google.com>
Reviewed-by: Hal Canary <halcanary@google.com>
- Hide SkImageEncoder class in private header.
- SkImageEncoder::Type becomes SkEncodedImageFormat
- SkEncodedFormat becomes SkEncodedImageFormat
- SkImageEncoder static functions replaced with
single function EncodeImage()
- utility wrappers for EncodeImage() are in
sk_tool_utils.h
TODO: remove link-time registration mechanism.
TODO: clean up clients use of API and flip the flag.
TODO: implement EncodeImage() in chromeium/skia/ext
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4909
Change-Id: Ib48b31fdc05cf23cda7f56ebfd67c841c149ce70
Reviewed-on: https://skia-review.googlesource.com/4909
Reviewed-by: Mike Reed <reed@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Hal Canary <halcanary@google.com>
This reverts commit 8240750718.
Reason for revert: Breaking WebView (chromium:663959)
Original change's description:
> Change SkCanvas to *not* inherit from SkRefCnt
>
> Definitely tricky for classes like SkNWayCanvas, where the caller (today)
> need not pay attention to ownership of the canvases it gave the NWay
> (after this CL, the caller *must* managed ownership)
>
> BUG=skia:
>
> GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4441
>
> DOCS_PREVIEW= https://skia.org/?cl=4441
>
> Change-Id: Ib1ac07a3cdf0686d78e7aaa4735d45cc90bea081
> Reviewed-on: https://skia-review.googlesource.com/4441
> Commit-Queue: Mike Reed <reed@google.com>
> Reviewed-by: Florin Malita <fmalita@chromium.org>
> Reviewed-by: Robert Phillips <robertphillips@google.com>
>
TBR=djsollen@google.com,mtklein@google.com,halcanary@google.com,robertphillips@google.com,fmalita@chromium.org,fmalita@google.com,reed@google.com,reviews@skia.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: I5e3b3e876b7d2c09833cf841801321033b6b968b
Reviewed-on: https://skia-review.googlesource.com/4687
Commit-Queue: Heather Miller <hcm@google.com>
Reviewed-by: Heather Miller <hcm@google.com>
Definitely tricky for classes like SkNWayCanvas, where the caller (today)
need not pay attention to ownership of the canvases it gave the NWay
(after this CL, the caller *must* managed ownership)
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4441
DOCS_PREVIEW= https://skia.org/?cl=4441
Change-Id: Ib1ac07a3cdf0686d78e7aaa4735d45cc90bea081
Reviewed-on: https://skia-review.googlesource.com/4441
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Reviewed-by: Robert Phillips <robertphillips@google.com>
It is moved to src/utils. It is almost a tool, but has two uses in
src/ports.
The existing SkOSFile.cpp is left empty for the time being since it is
mentioned in Chromium's BUILD.gn for Skia.
Change-Id: I3bb7f7c4214359eb6ab906bfe76737d20bf1d6c7
Reviewed-on: https://skia-review.googlesource.com/4536
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Ben Wagner <bungeman@google.com>
"Remove SkAutoTDelete." did not run trybots on these specific bots.
Change-Id: Ibfa731df387a90a78187b88c75483800981a691c
Reviewed-on: https://skia-review.googlesource.com/4387
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
Replace with std::unique_ptr.
Change-Id: I5806cfbb30515fcb20e5e66ce13fb5f3b8728176
Reviewed-on: https://skia-review.googlesource.com/4381
Commit-Queue: Ben Wagner <bungeman@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Our internal definition is (and will continue to be) that anything with
a color space is gamma correct. F16 is irrelevant (whether or not we
choose to support untagged F16). This makes these helpers less than
helpful, and lets us remove them from (public) API.
API change is just removal (of unused functions).
TBR=reed@google.com
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4228
Change-Id: Ia84a423548bfee14a3ba4a43d6d5b8c4686fb5ff
Reviewed-on: https://skia-review.googlesource.com/4228
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
This was always intended to be a temporary dependency to use for
testing. It has served its purpose.
Also, this has already been dropped (accidentally, I think) by
the new GN build.
TBR=reed@google.com
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4220
Change-Id: Ic72ee08bbfaf86ed86a4122fd38be2921eb1327e
Reviewed-on: https://skia-review.googlesource.com/4220
Reviewed-by: Matt Sarett <msarett@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Matt Sarett <msarett@google.com>
This also makes the required changed to src, tests, and tools. The few
public APIs modified by this change appear to be unused outside of Skia.
Removing these from the public API makes it easier to ensure users are
no longer using them.
This also updates GrGpu::wrapBackendXXX and the
::onWrapBackendXXX methods to clarify ownership.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2448593002
Review-Url: https://codereview.chromium.org/2448593002
565 cannot take the !writeTransparentPixels path, so disable it for
cases where we might have to take that path.
This only affects frames beyond the first. If the first frame has
a transparent pixel, it will be marked as non-opaque, so we cannot
decode to 565 anyway.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2441833002
Review-Url: https://codereview.chromium.org/2441833002
Prior to this CL, a kAnimated_Mode CodecSrc (which draws a strip of
all frames in an image) has the same name as a non-animated one. This
means that Gold compares the two. Someone triaging will see two very
different images (a strip versus a single image) and think one of them
is wrong.
With this change, the two will have different names so they will not
be compared with one another.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2446543003
Review-Url: https://codereview.chromium.org/2446543003
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>
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
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>
(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>
The refactoring breaks off A2B0 tag support into a separate
subclass of SkColorSpace_Base, while keeping the current
(besides CLUT) functionality in a XYZTRC subclass.
ICC profile loading is now aware of this and creates the A2B0
subclass when SkColorSpace::NewICC() is called on a profile
in need of the A2B0 functionality.
The LabPCSDemo GM loads a .icc profile containing a LAB PCS and
then runs a Lab->XYZ conversion on an image using it so we can
display it and test out the A2B0 SkColorSpace functionality,
sans a/b/m-curves, as well as the Lab->XYZ conversion code.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2389983002
Review-Url: https://codereview.chromium.org/2389983002
It will now reside in SkColorSpace_Base. Future work for SkColorSpace
will cause this function to not be desirable or sensible to call on
all SkColorSpaces. Call sites were changed to make a kSRGBLinear_Named
instead of kSRGB_Named -> makeLinearGamma() (the majority of cases),
and if that was not possible, SkColorSpace_Base::makeLinearGamma()
was called instead.
TBR=reed@google.com
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2412613005
Review-Url: https://codereview.chromium.org/2412613005
- perform version check in CreateProc for XfermodeImageFilter and ArithmeticImageFilter
This reverts commit 3ed485f424.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2992
Change-Id: Ib4a154cdd5f5d1dcac921ef50d53b79a2d6a1be8
Reviewed-on: https://skia-review.googlesource.com/2992
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Reed <reed@google.com>
I also had to cut it down to just a global atomic bool... as a field in a global singleton accessed through instance(), it's very hard to make threadsafe.
CQ_INCLUDE_TRYBOTS=master.client.skia:Test-Ubuntu-Clang-GCE-CPU-AVX2-x86_64-Release-TSAN-Trybot
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2937
Change-Id: If80be987906dd521fbe644d1d0d577009f06d0e3
Reviewed-on: https://skia-review.googlesource.com/2937
Reviewed-by: Yuqian Li <liyuqian@google.com>
Commit-Queue: Yuqian Li <liyuqian@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
This is a step towards using SkCodec in Chromium, where progressive
decoding is necessary.
Switch from using png_read_row (which expects all the data to be
available) to png_process_data, which uses callbacks when rows are
available.
Create a new API for SkCodec, which supports progressive decoding and
scanline decoding. Future changes will switch the other clients off of
startScanlineDecode and get/skip-Scanlines to the new API.
Remove SkCodec::kNone_ScanlineOrder, which was only used for interlaced
PNG images. In the new API, interlaced PNG fits kTopDown. Also remove
updateCurrScanline(), which was only used by the old implementation for
interlaced PNG.
DMSrcSink:
- In CodecSrc::kScanline_Mode, use the new method for scanline decoding
for the supported formats (just PNG and PNG-in-ICO for now).
fuzz.cpp:
- Remove reference to kNone_ScanlineOrder
SkCodec:
- Add new APIs:
- startIncrementalDecode
- incrementalDecode
- Remove kNone_SkScanlineOrder and updateCurrScanline()
- Set fDstInfo and fOptions in getPixels(). This may not be necessary
for all implementations, but it simplifies things for SkPngCodec.
SkPngCodec:
- Implement new APIs
- Switch from sk_read_fn/png_read_row etc to png_process_data
- Expand AutoCleanPng's role to decode the header and create the
SkPngCodec
- Make the interlaced PNG decoder report how many lines were
initialized during an incomplete decode
SkIcoCodec:
- Implement the new APIs; supported for PNG in ICO
SkSampledCodec:
- Call the new method for decoding scanlines, and fall back to the old
method if the new version is unimplemented
- Remove references to kNone_SkScanlineOrder
tests/CodecPartial:
- Add a test which decodes part of an image, then finishes the decode,
and compares it to the straightforward method
tests/CodecTest:
- Add a test which decodes all scanlines using the new method
- Repurpose the Codec_stripes test to decode using the new method in
sections rather than all at once
- In the method check(), add a parameter for whether the image supports
the new method of scanline decoding, and be explicit about whether an
image supports incomplete
- Test incomplete PNG decodes. We should have been doing it anyway for
non-interlaced (except for an image that is too small - one row), but
the new method supports interlaced incomplete as well
- Make test_invalid_parameters test the new method
- Add a test to ensure that it's safe to fall back to scanline decoding without
rewinding
BUG=skia:4211
The new version was generally faster than the old version (but not significantly so).
Some raw performance differences can be found at https://docs.google.com/a/google.com/spreadsheets/d/1Gis3aRCEa72qBNDRMgGDg3jD-pMgO-FXldlNF9ejo4o/
Design doc can be found at https://docs.google.com/a/google.com/document/d/11Mn8-ePDKwVEMCjs3nWwSjxcSpJ_Cu8DF57KNtUmgLM/
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1997703003
Review-Url: https://codereview.chromium.org/1997703003
The SkFontData type is not exposed externally, so any method which uses
it can be updated to use smart pointers without affecting external
users. Updating this first will make updating the public API much
easier.
This also updates SkStreamAsset* SkStream::NewFromFile(const char*) to
std::unique_ptr<SkStreamAsset> SkStream::MakeFromFile(const char*). It
appears that no one outside Skia is currently using SkStream::NewfromFile
so this is a good time to update it as well.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2339273002
Committed: https://skia.googlesource.com/skia/+/d8c2476a8b1e1e1a1771b17e8dd4db8645914f8c
Review-Url: https://codereview.chromium.org/2339273002
Reason for revert:
Killing Mac
Original issue's description:
> SkFontData to use smart pointers.
>
> The SkFontData type is not exposed externally, so any method which uses
> it can be updated to use smart pointers without affecting external
> users. Updating this first will make updating the public API much
> easier.
>
> This also updates SkStreamAsset* SkStream::NewFromFile(const char*) to
> std::unique_ptr<SkStreamAsset> SkStream::MakeFromFile(const char*). It
> appears that no one outside Skia is currently using SkStream::NewfromFile
> so this is a good time to update it as well.
>
> GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2339273002
>
> Committed: https://skia.googlesource.com/skia/+/d8c2476a8b1e1e1a1771b17e8dd4db8645914f8cTBR=mtklein@chromium.org,halcanary@google.com,mtklein@google.com,reed@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.chromium.org/2343933002
The SkFontData type is not exposed externally, so any method which uses
it can be updated to use smart pointers without affecting external
users. Updating this first will make updating the public API much
easier.
This also updates SkStreamAsset* SkStream::NewFromFile(const char*) to
std::unique_ptr<SkStreamAsset> SkStream::MakeFromFile(const char*). It
appears that no one outside Skia is currently using SkStream::NewfromFile
so this is a good time to update it as well.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2339273002
Review-Url: https://codereview.chromium.org/2339273002
Reason for revert:
Broken perf bots
Original issue's description:
> Checking for valid colorType, alphaType, colorSpace in SkCodec
>
> * Refactor to share code between SkPngCodec and SkWebpCodec
> * Didn't end up sharing with SkJpegCodec but did refactor
> that code a bit
> * Disallow conversions to F16 with non-linear color spaces
> * Fail to decode if we fail to create a SkColorSpaceXform
> (should be an assert soon). We used to fallback on a
> legacy decode if we failed to create the transform.
> * A bunch of name changes
>
> BUG=skia:
> GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2319293003
>
> Committed: https://skia.googlesource.com/skia/+/7a9900d6d34e437bb24beb5524a1f6488ae138c9TBR=scroggo@google.com,brianosman@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review-Url: https://codereview.chromium.org/2328663002
* Refactor to share code between SkPngCodec and SkWebpCodec
* Didn't end up sharing with SkJpegCodec but did refactor
that code a bit
* Disallow conversions to F16 with non-linear color spaces
* Fail to decode if we fail to create a SkColorSpaceXform
(should be an assert soon). We used to fallback on a
legacy decode if we failed to create the transform.
* A bunch of name changes
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2319293003
Review-Url: https://codereview.chromium.org/2319293003
Verify the rules that we're converging on for surfaces:
- For 8888, we only support sRGB-like gamma, or no color space at all.
- For F16, we require a color space, with linear gamma.
- For all other formats, we do not support color spaces.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2270823002
Review-Url: https://codereview.chromium.org/2270823002
SkLiteRecorder, a new SkCanvas, fills out SkLiteDL, a new SkDrawable.
This SkDrawable is a display list similar to SkRecord and SkBigPicture / SkRecordedDrawable, but with a few new design points inspired by Android and slimming paint:
1) SkLiteDL is structured as one big contiguous array rather than the two layer structure of SkRecord. This trades away flexibility and large-op-count performance for better data locality for small to medium size pictures.
2) We keep a global freelist of SkLiteDLs, both reusing the SkLiteDL struct itself and its contiguous byte array. This keeps the expected number of mallocs per display list allocation <1 (really, ~0) for cyclical use cases.
These two together mean recording is faster. Measuring against the code we use at head, SkLiteRecorder trends about ~3x faster across various size pictures, matching speed at 0 draws and beating the special-case 1-draw pictures we have today. (I.e. we won't need those special case implementations anymore, because they're slower than this new generic code.) This new strategy records 10 drawRects() in about the same time the old strategy took for 2.
This strategy stays the winner until at least 500 drawRect()s on my laptop, where I stopped checking.
A simpler alternative to freelisting is also possible (but not implemented here), where we allow the client to manually reset() an SkLiteDL for reuse when its refcnt is 1. That's essentially what we're doing with the freelist, except tracking what's available for reuse globally instead of making the client do it.
This code is not fully capable yet, but most of the key design points are there. The internal structure of SkLiteDL is the area I expect to be most volatile (anything involving Op), but its interface and the whole of SkLiteRecorder ought to be just about done.
You can run nanobench --match picture_overhead as a demo. Everything it exercises is fully fleshed out, so what it tests is an apples-to-apples comparison as far as recording costs go. I have not yet compared playback performance.
It should be simple to wrap this into an SkPicture subclass if we want.
I won't start proposing we replace anything old with anything new quite yet until I have more ducks in a row, but this does look pretty promising (similar to the SkRecord over old SkPicture change a couple years ago) and I'd like to land, experiment, iterate, especially with an eye toward Android.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2213333002
Review-Url: https://codereview.chromium.org/2213333002
This builds, links, and runs on Linux. Have not tried Mac.
I've tested is_debug={true,false} and is_component_build.
It's neat that the component build DM works, but it's also an indication I've missed an essential flag or two... it shouldn't work. :)
The GPU backend isn't working yet, but all the software configurations I've tried look good.
This fleshes out all the other parts of SkCodec too... I noticed we weren't able to decode gifs or webp.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2188643002
Review-Url: https://codereview.chromium.org/2188643002
201295.jpg on HP z620
(300x280, most common form of sRGB profile)
QCMS Xform 0.495 ms
Skia Old Xform 0.235 ms
Skia NEW Xform 0.423 ms
Vs Old Code 0.56x
Vs QCMS 1.17x
So to summarize, we are now much slower than before,
but still a bit faster than QCMS. And now we are also
far more accurate than QCMS :).
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2060823003
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
Review-Url: https://codereview.chromium.org/2060823003
Instead of two synchronization systems (in_signal_handler, gMutex),
we can just use one. This simplifies the signal handler logic to:
- first thread through grabs the lock, prints what's running and a stack trace,
then exits
- all other threads just sit waiting on that lock until exit kills them
Previously I think all threads were racing to exit, which can kill the process
before the printing thread is done. That truncated the output, which is dumb.
Plus...
refactor slightly so that crash_handler() shows up at the top of the stack
trace rather than some odd name for a lambda inside setup_crash_handler().
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2051863002
Review-Url: https://codereview.chromium.org/2051863002
$ git grep -l '<windows.h>' include src
include/private/SkLeanWindows.h
$ git grep -l SkLeanWindows.h | grep '\.h$'
include/ports/SkTypeface_win.h
include/utils/win/SkHRESULT.h
include/utils/win/SkTScopedComPtr.h
include/views/SkEvent.h
src/core/SkMathPriv.h
src/ports/SkTypeface_win_dw.h
src/utils/SkThreadUtils_win.h
src/utils/win/SkWGL.h
The same for `#include <intrin.h>` that was found in SkMath.h.
Those functions that needed it are moved to SkMathPriv.h.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2041943002
CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win_chromium_compile_dbg_ng,win_chromium_compile_rel_ng
Review-Url: https://codereview.chromium.org/2041943002
Reason for revert:
Still causing problems in Google3, e.g.
https://test.corp.google.com/ui#cl=124138817&flags=CAMQBQ==&id=OCL:124138817:BASE:124139560:1465227435491:219ffbdb&t=//third_party/skia/HEAD:dm
Original issue's description:
> Make SkPngCodec decode progressively.
>
> This is a step towards using SkCodec in Chromium, where progressive
> decoding is necessary.
>
> Switch from using png_read_row (which expects all the data to be
> available) to png_process_data, which uses callbacks when rows are
> available.
>
> Create a new API for SkCodec, which supports progressive decoding and
> scanline decoding. Future changes will switch the other clients off of
> startScanlineDecode and get/skip-Scanlines to the new API.
>
> Remove SkCodec::kNone_ScanlineOrder, which was only used for interlaced
> PNG images. In the new API, interlaced PNG fits kTopDown. Also remove
> updateCurrScanline(), which was only used by the old implementation for
> interlaced PNG.
>
> DMSrcSink:
> - In CodecSrc::kScanline_Mode, use the new method for scanline decoding
> for the supported formats (just PNG and PNG-in-ICO for now).
>
> fuzz.cpp:
> - Remove reference to kNone_ScanlineOrder
>
> SkCodec:
> - Add new APIs:
> - startIncrementalDecode
> - incrementalDecode
> - Remove kNone_SkScanlineOrder and updateCurrScanline()
>
> SkPngCodec:
> - Implement new APIs
> - Switch from sk_read_fn/png_read_row etc to png_process_data
> - Expand AutoCleanPng's role to decode the header and create the
> SkPngCodec
> - Make the interlaced PNG decoder report how many lines were
> initialized during an incomplete decode
> - Make initializeSwizzler return a bool instead of an SkCodec::Result
> (It only returned kSuccess or kInvalidInput anyway)
>
> SkIcoCodec:
> - Implement the new APIs; supported for PNG in ICO
>
> SkSampledCodec:
> - Call the new method for decoding scanlines, and fall back to the old
> method if the new version is unimplemented
> - Remove references to kNone_SkScanlineOrder
>
> tests/CodecPartial:
> - Add a test which decodes part of an image, then finishes the decode,
> and compares it to the straightforward method
>
> tests/CodecTest:
> - Add a test which decodes all scanlines using the new method
> - Repurpose the Codec_stripes test to decode using the new method in
> sections rather than all at once
> - In the method check(), add a parameter for whether the image supports
> the new method of scanline decoding, and be explicit about whether an
> image supports incomplete
> - Test incomplete PNG decodes. We should have been doing it anyway for
> non-interlaced (except for an image that is too small - one row), but
> the new method supports interlaced incomplete as well
> - Make test_invalid_parameters test the new method
> - Add a test to ensure that it's safe to fall back to scanline decoding without
> rewinding
>
> BUG=skia:4211
>
> The new version was generally faster than the old version (but not significantly so).
>
> Some raw performance differences can be found at https://docs.google.com/a/google.com/spreadsheets/d/1Gis3aRCEa72qBNDRMgGDg3jD-pMgO-FXldlNF9ejo4o/
>
> Design doc can be found at https://docs.google.com/a/google.com/document/d/11Mn8-ePDKwVEMCjs3nWwSjxcSpJ_Cu8DF57KNtUmgLM/
>
> GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1997703003
>
> Committed: https://skia.googlesource.com/skia/+/a4b09a117d4d1ba5dda372e6a2323e653766539e
>
> Committed: https://skia.googlesource.com/skia/+/30e78c9737ff4861dc4e3fa1e4cd010680ed6965
>
> Committed: https://skia.googlesource.com/skia/+/6fb2391b2cc83ee2160b4e994faa8128975acc1fTBR=reed@google.com,msarett@google.com,scroggo@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=skia:4211
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2044573002
Review-Url: https://codereview.chromium.org/2044573002
This is a step towards using SkCodec in Chromium, where progressive
decoding is necessary.
Switch from using png_read_row (which expects all the data to be
available) to png_process_data, which uses callbacks when rows are
available.
Create a new API for SkCodec, which supports progressive decoding and
scanline decoding. Future changes will switch the other clients off of
startScanlineDecode and get/skip-Scanlines to the new API.
Remove SkCodec::kNone_ScanlineOrder, which was only used for interlaced
PNG images. In the new API, interlaced PNG fits kTopDown. Also remove
updateCurrScanline(), which was only used by the old implementation for
interlaced PNG.
DMSrcSink:
- In CodecSrc::kScanline_Mode, use the new method for scanline decoding
for the supported formats (just PNG and PNG-in-ICO for now).
fuzz.cpp:
- Remove reference to kNone_ScanlineOrder
SkCodec:
- Add new APIs:
- startIncrementalDecode
- incrementalDecode
- Remove kNone_SkScanlineOrder and updateCurrScanline()
SkPngCodec:
- Implement new APIs
- Switch from sk_read_fn/png_read_row etc to png_process_data
- Expand AutoCleanPng's role to decode the header and create the
SkPngCodec
- Make the interlaced PNG decoder report how many lines were
initialized during an incomplete decode
- Make initializeSwizzler return a bool instead of an SkCodec::Result
(It only returned kSuccess or kInvalidInput anyway)
SkIcoCodec:
- Implement the new APIs; supported for PNG in ICO
SkSampledCodec:
- Call the new method for decoding scanlines, and fall back to the old
method if the new version is unimplemented
- Remove references to kNone_SkScanlineOrder
tests/CodecPartial:
- Add a test which decodes part of an image, then finishes the decode,
and compares it to the straightforward method
tests/CodecTest:
- Add a test which decodes all scanlines using the new method
- Repurpose the Codec_stripes test to decode using the new method in
sections rather than all at once
- In the method check(), add a parameter for whether the image supports
the new method of scanline decoding, and be explicit about whether an
image supports incomplete
- Test incomplete PNG decodes. We should have been doing it anyway for
non-interlaced (except for an image that is too small - one row), but
the new method supports interlaced incomplete as well
- Make test_invalid_parameters test the new method
- Add a test to ensure that it's safe to fall back to scanline decoding without
rewinding
BUG=skia:4211
The new version was generally faster than the old version (but not significantly so).
Some raw performance differences can be found at https://docs.google.com/a/google.com/spreadsheets/d/1Gis3aRCEa72qBNDRMgGDg3jD-pMgO-FXldlNF9ejo4o/
Design doc can be found at https://docs.google.com/a/google.com/document/d/11Mn8-ePDKwVEMCjs3nWwSjxcSpJ_Cu8DF57KNtUmgLM/
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1997703003
Committed: https://skia.googlesource.com/skia/+/a4b09a117d4d1ba5dda372e6a2323e653766539e
Committed: https://skia.googlesource.com/skia/+/30e78c9737ff4861dc4e3fa1e4cd010680ed6965
Review-Url: https://codereview.chromium.org/1997703003
Reason for revert:
Still breaking Google3 e.g.:
https://sponge.corp.google.com/target?id=9261d31b-34fc-4f0f-981e-f92f7c5cea2c&target=//third_party/skia/HEAD:dm#shard=1|run=1|attempt=1|page=-1
https://test.corp.google.com/ui#cl=123773095&flags=CAMQBQ==&id=OCL:123773095:BASE:123773415:1464804876959:b0ea9b1c&t=//third_party/skia/HEAD:dm
Original issue's description:
> Make SkPngCodec decode progressively.
>
> This is a step towards using SkCodec in Chromium, where progressive
> decoding is necessary.
>
> Switch from using png_read_row (which expects all the data to be
> available) to png_process_data, which uses callbacks when rows are
> available.
>
> Create a new API for SkCodec, which supports progressive decoding and
> scanline decoding. Future changes will switch the other clients off of
> startScanlineDecode and get/skip-Scanlines to the new API.
>
> Remove SkCodec::kNone_ScanlineOrder, which was only used for interlaced
> PNG images. In the new API, interlaced PNG fits kTopDown. Also remove
> updateCurrScanline(), which was only used by the old implementation for
> interlaced PNG.
>
> DMSrcSink:
> - In CodecSrc::kScanline_Mode, use the new method for scanline decoding
> for the supported formats (just PNG and PNG-in-ICO for now).
>
> fuzz.cpp:
> - Remove reference to kNone_ScanlineOrder
>
> SkCodec:
> - Add new APIs:
> - startIncrementalDecode
> - incrementalDecode
> - Remove kNone_SkScanlineOrder and updateCurrScanline()
>
> SkPngCodec:
> - Implement new APIs
> - Switch from sk_read_fn/png_read_row etc to png_process_data
> - Expand AutoCleanPng's role to decode the header and create the
> SkPngCodec
> - Make the interlaced PNG decoder report how many lines were
> initialized during an incomplete decode
> - Make initializeSwizzler return a bool instead of an SkCodec::Result
> (It only returned kSuccess or kInvalidInput anyway)
>
> SkIcoCodec:
> - Implement the new APIs; supported for PNG in ICO
>
> SkSampledCodec:
> - Call the new method for decoding scanlines, and fall back to the old
> method if the new version is unimplemented
> - Remove references to kNone_SkScanlineOrder
>
> tests/CodecPartial:
> - Add a test which decodes part of an image, then finishes the decode,
> and compares it to the straightforward method
>
> tests/CodecTest:
> - Add a test which decodes all scanlines using the new method
> - Repurpose the Codec_stripes test to decode using the new method in
> sections rather than all at once
> - In the method check(), add a parameter for whether the image supports
> the new method of scanline decoding, and be explicit about whether an
> image supports incomplete
> - Test incomplete PNG decodes. We should have been doing it anyway for
> non-interlaced (except for an image that is too small - one row), but
> the new method supports interlaced incomplete as well
> - Make test_invalid_parameters test the new method
> - Add a test to ensure that it's safe to fall back to scanline decoding without
> rewinding
>
> BUG=skia:4211
>
> The new version was generally faster than the old version (but not significantly so).
>
> Some raw performance differences can be found at https://docs.google.com/a/google.com/spreadsheets/d/1Gis3aRCEa72qBNDRMgGDg3jD-pMgO-FXldlNF9ejo4o/
>
> Design doc can be found at https://docs.google.com/a/google.com/document/d/11Mn8-ePDKwVEMCjs3nWwSjxcSpJ_Cu8DF57KNtUmgLM/
>
> GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1997703003
>
> Committed: https://skia.googlesource.com/skia/+/a4b09a117d4d1ba5dda372e6a2323e653766539e
>
> Committed: https://skia.googlesource.com/skia/+/30e78c9737ff4861dc4e3fa1e4cd010680ed6965TBR=reed@google.com,msarett@google.com,scroggo@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:4211
Review-Url: https://codereview.chromium.org/2026383002
This is a step towards using SkCodec in Chromium, where progressive
decoding is necessary.
Switch from using png_read_row (which expects all the data to be
available) to png_process_data, which uses callbacks when rows are
available.
Create a new API for SkCodec, which supports progressive decoding and
scanline decoding. Future changes will switch the other clients off of
startScanlineDecode and get/skip-Scanlines to the new API.
Remove SkCodec::kNone_ScanlineOrder, which was only used for interlaced
PNG images. In the new API, interlaced PNG fits kTopDown. Also remove
updateCurrScanline(), which was only used by the old implementation for
interlaced PNG.
DMSrcSink:
- In CodecSrc::kScanline_Mode, use the new method for scanline decoding
for the supported formats (just PNG and PNG-in-ICO for now).
fuzz.cpp:
- Remove reference to kNone_ScanlineOrder
SkCodec:
- Add new APIs:
- startIncrementalDecode
- incrementalDecode
- Remove kNone_SkScanlineOrder and updateCurrScanline()
SkPngCodec:
- Implement new APIs
- Switch from sk_read_fn/png_read_row etc to png_process_data
- Expand AutoCleanPng's role to decode the header and create the
SkPngCodec
- Make the interlaced PNG decoder report how many lines were
initialized during an incomplete decode
- Make initializeSwizzler return a bool instead of an SkCodec::Result
(It only returned kSuccess or kInvalidInput anyway)
SkIcoCodec:
- Implement the new APIs; supported for PNG in ICO
SkSampledCodec:
- Call the new method for decoding scanlines, and fall back to the old
method if the new version is unimplemented
- Remove references to kNone_SkScanlineOrder
tests/CodecPartial:
- Add a test which decodes part of an image, then finishes the decode,
and compares it to the straightforward method
tests/CodecTest:
- Add a test which decodes all scanlines using the new method
- Repurpose the Codec_stripes test to decode using the new method in
sections rather than all at once
- In the method check(), add a parameter for whether the image supports
the new method of scanline decoding, and be explicit about whether an
image supports incomplete
- Test incomplete PNG decodes. We should have been doing it anyway for
non-interlaced (except for an image that is too small - one row), but
the new method supports interlaced incomplete as well
- Make test_invalid_parameters test the new method
- Add a test to ensure that it's safe to fall back to scanline decoding without
rewinding
BUG=skia:4211
The new version was generally faster than the old version (but not significantly so).
Some raw performance differences can be found at https://docs.google.com/a/google.com/spreadsheets/d/1Gis3aRCEa72qBNDRMgGDg3jD-pMgO-FXldlNF9ejo4o/
Design doc can be found at https://docs.google.com/a/google.com/document/d/11Mn8-ePDKwVEMCjs3nWwSjxcSpJ_Cu8DF57KNtUmgLM/
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1997703003
Committed: https://skia.googlesource.com/skia/+/a4b09a117d4d1ba5dda372e6a2323e653766539e
Review-Url: https://codereview.chromium.org/1997703003
Reason for revert:
This is failing tests and then crashing on Google3 [1]. The crashes are fixed by crrev.com/2026873002, but to fix the builder we'll need to upgrade its version of libpng.
[1] https://sponge.corp.google.com/target?id=e545ef55-4da4-4931-9524-1ac92acb61b1&target=//third_party/skia/HEAD:dm#shard=1|run=1|attempt=1|page=-1
Original issue's description:
> Make SkPngCodec decode progressively.
>
> This is a step towards using SkCodec in Chromium, where progressive
> decoding is necessary.
>
> Switch from using png_read_row (which expects all the data to be
> available) to png_process_data, which uses callbacks when rows are
> available.
>
> Create a new API for SkCodec, which supports progressive decoding and
> scanline decoding. Future changes will switch the other clients off of
> startScanlineDecode and get/skip-Scanlines to the new API.
>
> Remove SkCodec::kNone_ScanlineOrder, which was only used for interlaced
> PNG images. In the new API, interlaced PNG fits kTopDown. Also remove
> updateCurrScanline(), which was only used by the old implementation for
> interlaced PNG.
>
> DMSrcSink:
> - In CodecSrc::kScanline_Mode, use the new method for scanline decoding
> for the supported formats (just PNG and PNG-in-ICO for now).
>
> fuzz.cpp:
> - Remove reference to kNone_ScanlineOrder
>
> SkCodec:
> - Add new APIs:
> - startIncrementalDecode
> - incrementalDecode
> - Remove kNone_SkScanlineOrder and updateCurrScanline()
>
> SkPngCodec:
> - Implement new APIs
> - Switch from sk_read_fn/png_read_row etc to png_process_data
> - Expand AutoCleanPng's role to decode the header and create the
> SkPngCodec
> - Make the interlaced PNG decoder report how many lines were
> initialized during an incomplete decode
> - Make initializeSwizzler return a bool instead of an SkCodec::Result
> (It only returned kSuccess or kInvalidInput anyway)
>
> SkIcoCodec:
> - Implement the new APIs; supported for PNG in ICO
>
> SkSampledCodec:
> - Call the new method for decoding scanlines, and fall back to the old
> method if the new version is unimplemented
> - Remove references to kNone_SkScanlineOrder
>
> tests/CodecPartial:
> - Add a test which decodes part of an image, then finishes the decode,
> and compares it to the straightforward method
>
> tests/CodecTest:
> - Add a test which decodes all scanlines using the new method
> - Repurpose the Codec_stripes test to decode using the new method in
> sections rather than all at once
> - In the method check(), add a parameter for whether the image supports
> the new method of scanline decoding, and be explicit about whether an
> image supports incomplete
> - Test incomplete PNG decodes. We should have been doing it anyway for
> non-interlaced (except for an image that is too small - one row), but
> the new method supports interlaced incomplete as well
> - Make test_invalid_parameters test the new method
> - Add a test to ensure that it's safe to fall back to scanline decoding without
> rewinding
>
> BUG=skia:4211
>
> The new version was generally faster than the old version (but not significantly so).
>
> Some raw performance differences can be found at https://docs.google.com/a/google.com/spreadsheets/d/1Gis3aRCEa72qBNDRMgGDg3jD-pMgO-FXldlNF9ejo4o/
>
> Design doc can be found at https://docs.google.com/a/google.com/document/d/11Mn8-ePDKwVEMCjs3nWwSjxcSpJ_Cu8DF57KNtUmgLM/
>
> GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1997703003
>
> Committed: https://skia.googlesource.com/skia/+/a4b09a117d4d1ba5dda372e6a2323e653766539eTBR=reed@google.com,msarett@google.com,scroggo@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:4211
Review-Url: https://codereview.chromium.org/2023103002
This is a step towards using SkCodec in Chromium, where progressive
decoding is necessary.
Switch from using png_read_row (which expects all the data to be
available) to png_process_data, which uses callbacks when rows are
available.
Create a new API for SkCodec, which supports progressive decoding and
scanline decoding. Future changes will switch the other clients off of
startScanlineDecode and get/skip-Scanlines to the new API.
Remove SkCodec::kNone_ScanlineOrder, which was only used for interlaced
PNG images. In the new API, interlaced PNG fits kTopDown. Also remove
updateCurrScanline(), which was only used by the old implementation for
interlaced PNG.
DMSrcSink:
- In CodecSrc::kScanline_Mode, use the new method for scanline decoding
for the supported formats (just PNG and PNG-in-ICO for now).
fuzz.cpp:
- Remove reference to kNone_ScanlineOrder
SkCodec:
- Add new APIs:
- startIncrementalDecode
- incrementalDecode
- Remove kNone_SkScanlineOrder and updateCurrScanline()
SkPngCodec:
- Implement new APIs
- Switch from sk_read_fn/png_read_row etc to png_process_data
- Expand AutoCleanPng's role to decode the header and create the
SkPngCodec
- Make the interlaced PNG decoder report how many lines were
initialized during an incomplete decode
- Make initializeSwizzler return a bool instead of an SkCodec::Result
(It only returned kSuccess or kInvalidInput anyway)
SkIcoCodec:
- Implement the new APIs; supported for PNG in ICO
SkSampledCodec:
- Call the new method for decoding scanlines, and fall back to the old
method if the new version is unimplemented
- Remove references to kNone_SkScanlineOrder
tests/CodecPartial:
- Add a test which decodes part of an image, then finishes the decode,
and compares it to the straightforward method
tests/CodecTest:
- Add a test which decodes all scanlines using the new method
- Repurpose the Codec_stripes test to decode using the new method in
sections rather than all at once
- In the method check(), add a parameter for whether the image supports
the new method of scanline decoding, and be explicit about whether an
image supports incomplete
- Test incomplete PNG decodes. We should have been doing it anyway for
non-interlaced (except for an image that is too small - one row), but
the new method supports interlaced incomplete as well
- Make test_invalid_parameters test the new method
- Add a test to ensure that it's safe to fall back to scanline decoding without
rewinding
BUG=skia:4211
The new version was generally faster than the old version (but not significantly so).
Some raw performance differences can be found at https://docs.google.com/a/google.com/spreadsheets/d/1Gis3aRCEa72qBNDRMgGDg3jD-pMgO-FXldlNF9ejo4o/
Design doc can be found at https://docs.google.com/a/google.com/document/d/11Mn8-ePDKwVEMCjs3nWwSjxcSpJ_Cu8DF57KNtUmgLM/
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1997703003
Review-Url: https://codereview.chromium.org/1997703003
This will allow me to test and visualize some assumptions
on parsing and applying color profiles. Also, it should
help me find and fix bugs.
This is certainly not an optimized implementation, and, as
far as I know, it doesn't take any shortcuts to improve
performance. We'll probably want to do both of these
once we know where it fits in the pipeline.
Right now this test is only run on an arbitrary set of ~100
images from the top 10k skps. I'll continue to add more
"interesting" images and probably tweak the code as
necessary.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1995233003
Review-Url: https://codereview.chromium.org/1995233003
When decoding to 565 or Gray, allow the client to incorrectly ask for premul.
When checking whether it's possible to decode to 565, return whether the
source is opaque.
In DM, allow decoding to 565 or Gray, even if the client also asked for premul.
This fixes a bug introduced in crrev.com/1999593003 when we stopped ever
requesting Opaque, resulting in us not testing 565 or Gray.
BUG=skia:4616
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=1996993003
Review-Url: https://codereview.chromium.org/1996993003
Only JPEG and WEBP support native scaling, so only create a CodecSrc
with a scale for those types.
If I run
dm --src image --images resources
this cuts down the number of Srcs from 11063 to 8032. All of these
trimmed Srcs would have failed quickly for each Sink (3 Sinks with the
above flags), but this will avoid creating them.
It drops the runtime on my mac from 13.2s to 11.4s, for about a 14%
speedup.
BUG=skia:5307
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1999103002
Review-Url: https://codereview.chromium.org/1999103002
With the GPU backend, allow F16 render targets to be created (along with
any other renderable format). We were previously just falling back to 8888.
In SampleApp, if the window configuration is F16, don't render directly
to the primary surface (which is actually sRGB 8888). Intead, make an
off-screen F16 surface, then blit it back to the framebuffer when we're done.
In DM, clamp values outside of [0,1]. These were wrapping, producing very
incorrect images. (Many filters can trigger out-of-range values due to
ringing).
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1890923003
Review URL: https://codereview.chromium.org/1890923003
I was using SkRect::MakeLargest() as bounds, which is sort of nutso,
as that clearly is way out of bounds for how big a picture can feasibly
be, i.e. something closer to SkIRect::MakeLargest().
This was causing spurious quick rejects in drawPatch(). I didn't really
look much deeper to figure out why. It's easy enough to just feed it the
proper bounds of the entire content.
This means patch_primitive draws correctly in sp-8888 mode.
I also noticed the GM was too small... it clipped off most of its content.
So I've made it larger.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1865143002
Review URL: https://codereview.chromium.org/1865143002
Also added SkSurfaceProps to SkSpecialImage, so that Image -> Surface conversion can preserve the desired behavior during filtering.
Many small changes, including a bunch of comments about places where we may be losing information right now. My approach was to ensure that if anything fails, it will always fall back to "legacy" mode - gamma-correctness is opt-in, so I'll just have to feed things through as missing cases are exposed.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1838953007
Review URL: https://codereview.chromium.org/1845283003
The following are currently unused in Android, Google3, Chromium, and Mozilla:
- SkEvent
- SkTime::GetMSecs
- SK_TIME_FACTOR (also unused in Skia)
- SkAutoTime
I left uses of SkMSec more-or-less intact for SkEvent, SkAnimator, and SkInterpolator. SkInterpolator is used in Chromium, so I did not want to change the API. The views/ and animator/ code is crufty, so it didn't seem worthwhile to refactor it. Instead, I added SkEvent::GetMSecsSinceStartup, which is likely to be adequate for use in SampleApp.
I also left SkMSec where it is used to measure a duration rather than a timestamp. With the exception of SkMovie, which is used in Android, all of the uses appear to measure the execution time of a piece of code, which I would hope does not exceed 2^31 milliseconds.
Added skiatest::Timer to support a common idiom in tests where we want to measure the wallclock time in integer milliseconds. (Not used in tests/PathOpsSkpClipTest.cpp because it redefines things in Test.h.)
Removed tabs in tests/StrokerTest.cpp.
BUG=skia:4632
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1811613004
Review URL: https://codereview.chromium.org/1811613004
The C++ standard library uses the name "release" for the operation we call "detach".
Rewriting each "detach(" to "release(" brings us a step closer to using standard library types directly (e.g. std::unique_ptr instead of SkAutoTDelete).
This was a fairly blind transformation. There may have been unintentional conversions in here, but it's probably for the best to have everything uniformly say "release".
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1809733002
Review URL: https://codereview.chromium.org/1809733002
Reason for revert:
GM breakage. Changes to SkGr.cpp appear to be altering behavior on a variety of tests. Debugging...
Original issue's description:
> Progress on gamma-correctness in the GPU backend. Fixed conversion of color and profile type to pixel config, which makes many things "just work".
>
> Added (color=8888|f16|srgb) option to gpu configurations, along with gpuf16, gpusrgb, and anglesrgb predefined configs. Runs the gpu backend in gamma-correct mode (with either FP16 linear or sRGB 8888 frambuffers).
>
> BUG=skia:
> GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1750383002
>
> Committed: https://skia.googlesource.com/skia/+/a6f58194733c1c50e4fe5f98585e42344f29b6f0TBR=mtklein@google.com,bsalomon@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1755553003
- Use std::atomic directly.
- No more need for SkPODSpinlock or SK_DECLARE_STATIC_SPINLOCK.
Now simple code like this works as you'd hope:
static SkSpinlock gLock;
That is, it starts unlocked and there's no static initializer.
std::atomic_flag would make this terser and standard-guaranteed,
but ATOMIC_FLAG_INIT caused not-yet-implemented errors on MSVC 2013.
The generated code for this approach is identical.
It appears the implicit constructor is constexpr when all the member
initializers are. I'm hoping this way of producing constexpr constructors
without typing "constexpr" gives us a way to eliminate more SkFoo / SkBaseFoo
distinctions and SK_DECLARE_STATIC_FOO. This was certainly the easiest.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1734383002
Review URL: https://codereview.chromium.org/1734383002
Reason for revert:
Breaks Ubuntu and Mac CMAKE
Original issue's description:
> Make SkPicture/SkImageGenerator default to SkCodec
>
> Remove reference to SkImageDecoder from SkPicture. Make the default
> InstallPixelRefProc passed to CreateFromStream use
> SkImageGenerator::NewFromEncoded instead.
>
> Make SkImageGenerator::NewFromEncoded create an SkCodecImageGenerator.
> Remove the old version that used SkImageDecoder.
>
> Remove all versions of lazy_decode_bitmap/LazyDecodeBitmap. The default
> now behaves lazily.
>
> Update all clients to use the default.
>
> Move SkImageDecoderGenerator into KtxTest.cpp, and use it directly.
>
> BUG=skia:4691
> BUG=skia:4290
> GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1671193002
>
> Committed: https://skia.googlesource.com/skia/+/026388a01864c74208ad57d1ba4f711602d101c6TBR=msarett@google.com,reed@google.com,scroggo@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:4691
Review URL: https://codereview.chromium.org/1685963004
Remove reference to SkImageDecoder from SkPicture. Make the default
InstallPixelRefProc passed to CreateFromStream use
SkImageGenerator::NewFromEncoded instead.
Make SkImageGenerator::NewFromEncoded create an SkCodecImageGenerator.
Remove the old version that used SkImageDecoder.
Remove all versions of lazy_decode_bitmap/LazyDecodeBitmap. The default
now behaves lazily.
Update all clients to use the default.
Move SkImageDecoderGenerator into KtxTest.cpp, and use it directly.
BUG=skia:4691
BUG=skia:4290
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1671193002
Review URL: https://codereview.chromium.org/1671193002
RAW images use a lot of memory. Add a new FLAG to run one at a time so
we have less risk of running out of memory.
Isolate RAW images to their own thread on particular devices where our
images cause OOM errors.
Locally, this drops the max memory use from 3945 MB to 1664 MB (running only --image --images <RAW images we test>)
BUG=skia:4912
BUG=skia:4878
BUG=b/27035849
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1681553003
Review URL: https://codereview.chromium.org/1681553003
If a client requests unpremul or premul from an opaque SkCodec,
support it. The opaque image can be treated as any of them, though
it will be less efficient to draw than if the client had used
opaque.
Change the filling code (i.e. for incomplete images) to base its color on
the source alpha type. Prior to adding the support to decode opaque to
any, it was fine to use either source or dest (which would have yielded
the same result). If the client requests non-opaque, we do not want this
to switch the fill value from black to transparent. This also allows
simplifying the signatures for getFillValue and onGetFillValue.
In CodexTest, expect the same result when decoding opaque to *premul,
and compare to the opaque version.
BUG=skia:4616
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1641273003
Review URL: https://codereview.chromium.org/1641273003
Bump SK_IMAGE_VERSION to test the images in v2 in GoogleStorage, which
includes the images from v1 plus test images for SkRawCodec.
Only define skia_decodes_raw on platforms that support it, rather than
defining it always and checking additional conditions to determine
whether to support raw. Further, define it and SK_CODEC_DECODES_RAW
for all targets, so we can use the compile flag in other targets.
In DM, exclude the raw extensions if SK_CODEC_DECODES_RAW is not defined.
Blacklist raw extensions on NexusPlayer, which was running out of memory
when running them.
BUG=skia:4829
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1612113002
Review URL: https://codereview.chromium.org/1612113002
Reason for revert:
Speculative to fix windows bots
Original issue's description:
> Treat bad values passed to --images as a fatal error
>
> If an option is passed to --images that is either a non-existent path or
> a folder with no images matching the supported types, assume this is
> an error and exit, so they can supply a valid path instead.
>
> Share code between DM and nanobench in SkCommonFlags.
>
> nanobench now behaves more like DM - it will check a directory for
> images that match the supported extensions.
>
> Only consider image paths ending in RAW suffixes as images if
> SK_CODE_DECODES_RAW is defined. This prevents us from seeing failure
> to decode errors on platforms that cannot decode it.
>
> GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1611323004
>
> Committed: https://skia.googlesource.com/skia/+/7579786f3bd5a8fda84a1abc45b16213c3371f93TBR=mtklein@google.com,borenet@google.com,msarett@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
# Not skipping CQ checks because original CL landed more than 1 days ago.
Review URL: https://codereview.chromium.org/1653543002
If an option is passed to --images that is either a non-existent path or
a folder with no images matching the supported types, assume this is
an error and exit, so they can supply a valid path instead.
Share code between DM and nanobench in SkCommonFlags.
nanobench now behaves more like DM - it will check a directory for
images that match the supported extensions.
Only consider image paths ending in RAW suffixes as images if
SK_CODE_DECODES_RAW is defined. This prevents us from seeing failure
to decode errors on platforms that cannot decode it.
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1611323004
Review URL: https://codereview.chromium.org/1611323004
- add ViaPicture
- run ViaPicture on most bots
- run ViaSecondPicture (tests SkPictureRecorder reuse) and ViaTwice (tests caching) on some bots
- extend ViaSerialization reference checking to ViaPicture, ViaSecondPicture,
ViaSingletonPictures, and ViaTwice
- suppress current reference check failures with --blacklist
I'm open to following up on changing how those suppressions work.
Passing --nocheck turns off these invariant checks, letting us debug failures with normal image diff tools.
CQ_EXTRA_TRYBOTS=client.skia:Test-Win8-MSVC-ShuttleB-CPU-AVX2-x86_64-Release-Trybot
BUG=skia:4769
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1569823006
Review URL: https://codereview.chromium.org/1569823006
