| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Our codec generator will now preserve any asked-for color space, and
convert the encoded data to that representation. Cacherator now
allows decoding an image to both legacy (nullptr color space), and
color-correct formats. In color-correct mode, we choose the best
decoded format, based on the original properties, and our backend's
capabilities. Preference is given to the native format, when it's
already texturable (sRGB 8888 or F16 linear). Otherwise, we prefer
linear F16, and fall back to sRGB when that's not an option.
Re-land (and fix) of:
https://skia-review.googlesource.com/c/4438/
https://skia-review.googlesource.com/c/4796/
BUG=skia:5907
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4838
Change-Id: I20ff972ffe1c7e6535ddc501e2a8ab8c246e4061
Reviewed-on: https://skia-review.googlesource.com/4838
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Matt Sarett <msarett@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit c73a1ecbed64652b3d7aa8dc6face9a2205ce830.
Reason for revert: ANGLE and CommandBuffer failures
Original change's description:
> Support decoding images to multiple formats, depending on usage
>
> Our codec generator will now preserve any asked-for color space, and
> convert the encoded data to that representation. Cacherator now
> allows decoding an image to both legacy (nullptr color space), and
> color-correct formats. In color-correct mode, we choose the best
> decoded format, based on the original properties, and our backend's
> capabilities. Preference is given to the native format, when it's
> already texturable (sRGB 8888 or F16 linear). Otherwise, we prefer
> linear F16, and fall back to sRGB when that's not an option.
>
> BUG=skia:5907
>
> GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4438
>
> Change-Id: I847c243dcfb72d8c0f1f6fc73c09547adea933f0
> Reviewed-on: https://skia-review.googlesource.com/4438
> Reviewed-by: Matt Sarett <msarett@google.com>
> Commit-Queue: Brian Osman <brianosman@google.com>
>
TBR=mtklein@google.com,bsalomon@google.com,msarett@google.com,brianosman@google.com,reed@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: I1818f937464573d601f64e5a1f1eb43f5a778f4e
Reviewed-on: https://skia-review.googlesource.com/4832
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Our codec generator will now preserve any asked-for color space, and
convert the encoded data to that representation. Cacherator now
allows decoding an image to both legacy (nullptr color space), and
color-correct formats. In color-correct mode, we choose the best
decoded format, based on the original properties, and our backend's
capabilities. Preference is given to the native format, when it's
already texturable (sRGB 8888 or F16 linear). Otherwise, we prefer
linear F16, and fall back to sRGB when that's not an option.
BUG=skia:5907
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4438
Change-Id: I847c243dcfb72d8c0f1f6fc73c09547adea933f0
Reviewed-on: https://skia-review.googlesource.com/4438
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4554
Change-Id: Ic9105a2806b915fc56b6810a80dd444561d0d959
Reviewed-on: https://skia-review.googlesource.com/4554
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Matt Sarett <msarett@google.com>
|
|
|
|
|
|
|
|
|
|
|
| |
BUG:642462
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4560
Change-Id: I22891ce1e0b3a1bedefc34dadd5cf34dfc301b79
Reviewed-on: https://skia-review.googlesource.com/4560
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Matt Sarett <msarett@google.com>
|
|
|
|
|
|
|
|
|
| |
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4480
Change-Id: I7d3219b02ad5094785e1b7635a9482e69aadbc8c
Reviewed-on: https://skia-review.googlesource.com/4480
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Hal Canary <halcanary@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implements color space xforms and F16 for SkRawCodec and SkWbmpCodec.
BUG=skia:4895
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4459
Change-Id: I8c72918e46387350b49a9811ce654d26b1ab352a
Reviewed-on: https://skia-review.googlesource.com/4459
Commit-Queue: Matt Sarett <msarett@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=skia:4895
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4396
Change-Id: I7c521760891852daf4f3933ecf02dc08acec64c0
Reviewed-on: https://skia-review.googlesource.com/4396
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Matt Sarett <msarett@google.com>
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4439
Change-Id: I274930fd947585e7b2a4716c5c51aef267574ddd
Reviewed-on: https://skia-review.googlesource.com/4439
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Matt Sarett <msarett@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Thanks to Gold for catching this.
BUG=skia:4895
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4426
Change-Id: Icc816d933e9e2fd312858a5430fa21a47722563e
Reviewed-on: https://skia-review.googlesource.com/4426
Commit-Queue: Matt Sarett <msarett@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=skia:4895
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4390
Change-Id: I9cb727e7f13816b0ac882f62ec635a4528c3a524
Reviewed-on: https://skia-review.googlesource.com/4390
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Matt Sarett <msarett@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit d851795e7992565c1eb2b9474ee5ad01d1a01fad.
Reason for revert: <INSERT REASONING HERE>
Original change's description:
> Add F16, SkColorSpaceXform support to SkBmpCodec
>
> BUG=skia:4895
>
> GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4300
>
> Change-Id: I2f2b8d3854ea3a8c5904dd3c5bea0342e2be9789
> Reviewed-on: https://skia-review.googlesource.com/4300
> Reviewed-by: Leon Scroggins <scroggo@google.com>
> Commit-Queue: Matt Sarett <msarett@google.com>
>
Speculative revert for MSAN
TBR=borenet@google.com,msarett@google.com,scroggo@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: Ie48c03c0c3156267763fbcf96818477567c5069d
Reviewed-on: https://skia-review.googlesource.com/4378
Commit-Queue: Matt Sarett <msarett@google.com>
Reviewed-by: Matt Sarett <msarett@google.com>
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=skia:4895
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4300
Change-Id: I2f2b8d3854ea3a8c5904dd3c5bea0342e2be9789
Reviewed-on: https://skia-review.googlesource.com/4300
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Matt Sarett <msarett@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This class is already just an alias for std::unique_ptr<T[]>, so replace
all uses with that and delete the class.
CQ_INCLUDE_TRYBOTS=master.client.skia:Test-Ubuntu-Clang-GCE-CPU-AVX2-x86_64-Debug-ASAN-Trybot,Test-Ubuntu-Clang-Golo-GPU-GT610-x86_64-Debug-ASAN-Trybot
Change-Id: I40668d398356a22da071ee791666c7f728b59266
Reviewed-on: https://skia-review.googlesource.com/4362
Reviewed-by: Mike Reed <reed@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a new accessor to retrieve the repetition count.
Remove constants (and corresponding copyright) in SkCodecAnimation.
These may make sense for the calling code, but are not needed here.
kRepetitionCountInfinite corresponds to Blink's kAnimationLoopInfinite.
Move cLoopCountNotSeen to private. It is used to determine whether we
still need to parse. Add a new enum to the parse query - only parse
enough to determine the repetition count.
Unlike Chromium, SkGifCodec does not account for deleting the reader
(which SkGifCodec does not do) or failed decodes.
Add a test.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2447863002
Review-Url: https://codereview.chromium.org/2447863002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While investigating skbug.com/5883 I noticed that we use the color
table for the current frame even while recursively decoding frames that
the current frame depends on.
This CL updates fCurrColorTable, fCurrColorTableIsReal and fSwizzler
before decoding prior frames, and then sets them back afterwards.
Move telling the client about the color table into prepareToDecode,
since the other callers do not need to do so. (That is only necessary
for decoding to index 8, which is unsupported for frames with
dependencies.)
Add a test that exposes the bug. colorTables.gif has a local color
table in its second frame that does not match the global table used by
the first frame.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4208
Change-Id: Id2dc9e3283adfd92801d2f38726afa74574b1955
Reviewed-on: https://skia-review.googlesource.com/4208
Reviewed-by: Joost Ouwerling <joostouwerling@google.com>
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unmarked images should be treated as sRGB.
BUG=skia:4895
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4151
Change-Id: I5f8c308d22fd2d069cbfa89c5a5bb19ae6fde8bd
Reviewed-on: https://skia-review.googlesource.com/4151
Reviewed-by: Leon Scroggins <scroggo@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Matt Sarett <msarett@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TBR=reed@google.com
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4140
Change-Id: Ib1c477b6b56a100ea449ffa20bdf18041c044a78
Reviewed-on: https://skia-review.googlesource.com/4140
Reviewed-by: Matt Sarett <msarett@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Matt Sarett <msarett@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 0057ac11fccc82bc5b0c1bb0aefe838cc04efd13.
This was a speculative fix. Now that a proper fix has been introduced
(crrev.com/2450943002) we shouldn't need this one.
BUG=skia:5883
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4033
Change-Id: Ie7aae4fd18dac21b240085c3b5c4f3d46511cd75
Reviewed-on: https://skia-review.googlesource.com/4033
Commit-Queue: Leon Scroggins <scroggo@google.com>
Reviewed-by: Matt Sarett <msarett@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Writing transparent pixels is faster than the alternative, and we can
skip clearing the frame to transparent. We'll still clear if the image
is incomplete.
I ran
./out/Release/nanobench --images <images> --samples 100 --sourceType image --simpleCodec -v
over the GIFs we have on our bots, and found an average ~13% speedup.
Raw data is on sheet 2 of
https://docs.google.com/spreadsheets/d/19V-t9BfbFw5eiwBTKA1qOBkZbchjlTC5EIz6HFy-6RI/
(the sheet is named WriteTransparentPixels).
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2436183002
Review-Url: https://codereview.chromium.org/2436183002
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=skia:5887
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3940
Change-Id: I9e3ed6153a73277896ac067ef73918a41a0546b8
Reviewed-on: https://skia-review.googlesource.com/3940
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Matt Sarett <msarett@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since we will not draw anything later, we need to fill the frame with
the fill color.
NOTREECHECKS=true
BUG=skia:5883
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2450943002
Review-Url: https://codereview.chromium.org/2450943002
|
|
|
|
|
|
|
|
|
| |
NOTRY=true
NOTREECHECKS=true
TBR=mtklein@google.com
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2447223002
Review-Url: https://codereview.chromium.org/2447223002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Speculative fix for skbug.com/5883
We are hitting an assert (which I have not been able to repro - still
need to get the skp that triggers it) because we are trying to read
beyond the end of the color table. We use 8-bit indices, so 256 should
be enough to prevent going beyond the end. There is only one case when
we use a smaller color table - when it is a dummy. Make the dummy full
size.
NOTREECHECKS=true
BUG=skia:5883
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2452673002
Review-Url: https://codereview.chromium.org/2452673002
|
|
|
|
|
|
|
|
|
|
| |
To fix Google3
TBR=benjaminwagner@google.com
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2450753003
NOTREECHECKS=true
Review-Url: https://codereview.chromium.org/2450753003
|
|
|
|
|
|
|
|
| |
The former could violate One Definition Rule in Google3, since other
projects that are based on Chrome/webkit also have GIFImageReader.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2445653004
Review-Url: https://codereview.chromium.org/2445653004
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
crrev.com/2420843003 (DIFFERENT ISSUE) introduced some changes in
sampled images. (I already corrected the problem for interlaced PNGs
in crrev.com/2424353003.)
When deciding whether a row is needed, we need to subtract the starting
coordinate, similar to how we subtracted fFirstRow in SkPngCodec.
This should "fix" the remaining untriaged images in Gold (i.e. we will
go back to producing the original image).
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2440563002
Review-Url: https://chromiumcodereview.appspot.com/2440563002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
crrev.com/2420843003 (DIFFERENT ISSUE) resulted in a slight difference
in Gold for interlaced PNGs. The new images appeared to have slid down
slightly, implying that we sampled pixels higher (earlier) in the
image.
It turns out we were not truly taking get_start_coord into account.
This CL initializes the srcRow to consider get_start_coord, and should
fix the problem/difference.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2424353003
Review-Url: https://codereview.chromium.org/2424353003
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the initial patch, we modified the subset passed to incremental
decoding to account for sampling in Y. This allowed SkSampledCodec to
use a tighter bounds. But it also means that the implementation cannot
distinguish between lines that are excluded due to subsetting and those
excluded at the beginning and end due to sampling. This becomes
problematic in GIF (crrev.com/2045293002), which may need to fill,
requiring it to reconstruct the actual destination. In truth,
SkGifCodec does not need to support subsets, but cannot distinguish
between the tighter bounds and a true subset.
Fix this by passing the scaled subset to incremental decode, without
using the tighter bounds.
Make SkSampler::rowNeeded take the starting coordinate into account.
In SkPngCodec, compute the number of rows needed in the output, and use
that as a signal to stop.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2420843003
Review-Url: https://codereview.chromium.org/2420843003
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Original Commit Message:
"""
Avoid integer overflow in SkIcoCodec
Definitely good to avoid overflow here.
FWIW, this looks to be harmless for Android's current use.
They will just fail later on when trying to allocate the
bitmap.
BUG=skia:5857
"""
With the new test, ASAN also caught an integer overflow
bug in SkImageInfo. Fix this as well.
CQ_INCLUDE_TRYBOTS=master.client.skia:Test-Ubuntu-Clang-GCE-CPU-AVX2-x86_64-Debug-ASAN;master.client.skia.android:Test-Android-Clang-AndroidOne-CPU-MT6582-arm-Debug-GN_Android
BUG=skia:5857
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3568
Change-Id: I0d777a547850474ea6cea87e36efa05434e33635
Reviewed-on: https://skia-review.googlesource.com/3568
Reviewed-by: Kevin Lubick <kjlubick@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 20cba06a4bc9bde60b2dc37907d11ca81ba35ce8.
Reason for revert: <INSERT REASONING HERE>
TBR=msarett@google.com,scroggo@google.com,kjlubick@google.com,reviews@skia.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: Id8f48a90a7dc620f9c0ee2f419d14bae2b0c1e7e
Reviewed-on: https://skia-review.googlesource.com/3564
Commit-Queue: Matt Sarett <msarett@google.com>
Reviewed-by: Matt Sarett <msarett@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Definitely good to avoid overflow here.
FWIW, this looks to be harmless for Android's current use.
They will just fail later on when trying to allocate the
bitmap.
BUG=skia:5857
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3527
Change-Id: Ia1fb7d864d21ecdb127a1dd1a72cab8375cb43fb
Reviewed-on: https://skia-review.googlesource.com/3527
Commit-Queue: Matt Sarett <msarett@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Necessary because PNGs like to specify their gamma this way.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3402
Change-Id: I399984d611db907b115b345df1afc88d39326fbb
Reviewed-on: https://skia-review.googlesource.com/3402
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Matt Sarett <msarett@google.com>
|
|
|
|
|
|
|
| |
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2390263002
Review-Url: https://codereview.chromium.org/2390263002
|
|
|
|
|
|
|
| |
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2304753002
Review-Url: https://codereview.chromium.org/2304753002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When sampling, we previously had to figure out the number of rows that
were written to the output based on the value reported by
incrementalDecode. (We also messed up the first time - see the fix in
crrev.com/2343153003.)
Instead, make incrementalDecode report the actual number of rows
written to. This can be provided directly to fill.
Make SkPngCodec report the correct number of rows, by incrementing its
count when it actually writes to the destination.
This also will simplify my in progress GIF change.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2407543002
Review-Url: https://codereview.chromium.org/2407543002
|
|
|
|
|
|
|
|
|
| |
incrementalDecode is supposed to report the number of rows decoded. It
failed to if none were decoded (for an interlaced png). Fix the bug and
add a test.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2402063002
Review-Url: https://codereview.chromium.org/2402063002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
allRowsCallback was asserting that
rowNum - fFirstRow == fLinesDecoded
But it was expecting fFirstRow to be 0 (logically, it is, since we are
decoding all rows), and it never set it (because it doesn't really need
to, except for this assert). This is only a problem if we reuse an
SkPngCodec after previously scaling with it. Add a test that triggers
the assert, and fix it.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2401133002
Review-Url: https://codereview.chromium.org/2401133002
|
|
|
|
|
|
|
| |
BUG=skia:5820
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2391933004
Review-Url: https://codereview.chromium.org/2391933004
|
|
|
|
|
|
|
|
|
|
| |
This is immediately useful for webp and I think it's a fair guess
that BGRA src formats are not uncommon.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2353363008
Review-Url: https://codereview.chromium.org/2353363008
|
|
|
|
|
|
|
|
|
|
| |
There's no need to take sk_sp if we're not going to
ref the ptr.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2360863003
Review-Url: https://codereview.chromium.org/2360863003
|
|
|
|
|
|
|
|
|
|
|
|
| |
The bug occurs when filling after an incomplete sampled/subset
incremental decode.
I'm also adding many truncated test pngs.
BUG=skia:5769
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2343153003
Review-Url: https://codereview.chromium.org/2343153003
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Adds Float32 support to SkColorSpaceXform
* Changes API to allows clients to ask for F32, updates clients to
new API
* Adds Sk4f_load4 and Sk4f_store4 to SkNx
* Make use of new xform in SkGr.cpp
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2339233003
CQ_INCLUDE_TRYBOTS=master.client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
Committed: https://skia.googlesource.com/skia/+/43d6651111374b5d1e4ddd9030dcf079b448ec47
Review-Url: https://codereview.chromium.org/2339233003
|