TBR=reed@google.com
(No change to the public API, but changed a header file)
SkWebpCodec:
- Implement onGetFrameCount, onGetFrameInfo, and onGetRepetitionCount
- Respect the alpha reported by libwebp. Although the spec states that
it is only a hint, the libwebp encoder uses it properly. Respecting
allows us to draw opaque images faster and decode them to 565. This
also matches other SkCodecs (and Chromium).
- onGetPixels:
- Decode the frame requested, recursively decoding required frame if
necessary
- When blending with a prior frame, use SkRasterPipeline
SkCodec:
- Move check for negative index to getFrameInfo
- Reset the colorXform if one is not needed
SkCodecAnimation:
- Add new blend enum, for WebP's (and APNG's) non-blending option
SkFrameHolder:
- New base classes for frames and the owner of the frames, allowing
code sharing between SkWebpCodec and SkGifCodec (particularly for
determining whether a frame has alpha and what frame it depends on)
- When moving items from SkGIFFrameContext, use Skia conventions (i.e.
int instead of unsigned)
- Rename "delay time" to "duration", to match e.g. SkFrameInfo::
fDuration
SkGifImageReader:
- Move pieces to SkFrameHolder, and adapt to changes made in the
process
- Make setAlphaAndRequiredFrame (now on the base class SkFrameHolder)
more general to support webp, and add support for frames that do not
blend
- Change SkGIFFrameContext from a struct to a class, to match how we
use the distinction elsewhere (i.e. struct is a small object with
public fields)
- Rework hasTransparentPixel (now hasTransparency, since it returns true
in some cases where there is not a transparent pixel) to better fit
with the modified setAlphaAndRequiredFrame. Also be more consistent
when there is no transparent pixel but no color map.
- Simplify an if condition that was previously simplified in 2d61e717
but accidentally got reverted in a4db9be6
CodecAnimTest:
- Test new animated webp files
- Rearrange the test to more cleanly print alpha type mismatches for
the first frame
resources:
- webp-animated.webp
- animated webp from Chromium
- blendBG.webp
- new webp file using bits of webp-animated-semitransparent4.webp
from Chromium
- tests required frame and alpha when using the non-blending mode
- frames have the following properties:
- Frame 0: no alpha, fills screen
- Frame 1: alpha, fills screen
- Frame 2: no alpha, fills screen
- Frame 3: alpha, fills screen, blendBG
- Frame 4: no alpha, fills screen, blendBG
- Frame 5: alpha, blendBG
- Frame 6: covers 4, has alpha, blendBG
- also used to test decoding to 565 if the new frame data has alpha
but blends onto an opaque frame
DM.cpp:
- Test animated images to non-native 8888 and unpremul
DMSrcSink.cpp:
- Do not test non-native 8888 decodes to f16 dst
- Test unpremul decodes to f16
- Copy a frame of an animated image prior to drawing, since in unpremul
mode, the DM code will premultiply first.
Bug: skia: 3315
Change-Id: I4e55ae2ee5bc095b37a743bdcfac644be603b980
Reviewed-on: https://skia-review.googlesource.com/16707
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
Reviewed-by: Matt Sarett <msarett@google.com>
Summary of the new world...
--image
CodecSrc and ImageGenSrc tests run on:
(1) 8888 with kIgnore transfer fn behavior
(2) srgb with kRespect transfer fn behavior
(3) f16
AndroidCodecSrc and BRDCodecSrc tests run on:
(1) 8888, since SkAndroidCodec always uses kIgnore
(2) f16, since android uses f16
--colorImage
ColorCodecSrc tests run on:
(1) 8888 in kBaseline mode, so we can see what the raw pixels look like
(2) srgb in color correct modes
(3) f16 in color correct modes
Bug: skia:
Change-Id: I65d1a04051da6f94bf5e48f7bc610f482870dc75
Reviewed-on: https://skia-review.googlesource.com/17396
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Matt Sarett <msarett@google.com>
This is fairly aggressive in that it will break any client
that is currently using SkImageGenerator with kIndex8.
I'm guessing that we don't have any clients doing that.
Bug: skia:6620
Change-Id: Ifd16f5232bb3a9f759c225315c57492d917ed9ca
Reviewed-on: https://skia-review.googlesource.com/16601
Commit-Queue: Matt Sarett <msarett@google.com>
Reviewed-by: Mike Reed <reed@google.com>
If/when we double check these settings we can either re-add these parameters or change the code manually.
The driving goal here is to shrink GrRenderTargetOpList.
Change-Id: I7819de18f97e8282e8754e3438130f797ebb3c37
Reviewed-on: https://skia-review.googlesource.com/14381
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
This matches other Skia APIs. size_t was adopted from blink/
GIFImageReader.
Change-Id: Ic83e59f0942f597c4fb834e623acd9886ad483fe
Reviewed-on: https://skia-review.googlesource.com/13274
Reviewed-by: Mike Reed <reed@google.com>
Reviewed-by: Matt Sarett <msarett@google.com>
Reviewed-by: Chris Blume <cblume@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
guarded by SK_SUPPORT_OBSOLETE_LOCKPIXELS
needs https://codereview.chromium.org/2820873002/# to land first
Bug: skia:6481
Change-Id: I1c39902cbf6fe99f622adfa8192733b95f7fea09
Change-Id: I1c39902cbf6fe99f622adfa8192733b95f7fea09
Reviewed-on: https://skia-review.googlesource.com/13580
Reviewed-by: Florin Malita <fmalita@chromium.org>
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Mike Reed <reed@google.com>
Previosly, SkSize had a base class, which prevented it.
Also removes unused SkISize::clampNegToZero() and
SkSize::clampNegToZero().
Change-Id: I7b93b42f6f6381c66e294bbedee99ad53c6c3436
Reviewed-on: https://skia-review.googlesource.com/13187
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Hal Canary <halcanary@google.com>
Motivation: We may want to make SkMultiPictureDocument.h public in the
future.
Change-Id: Ie97b88d51a179c2283155d65bcadee32178115ca
Reviewed-on: https://skia-review.googlesource.com/11402
Commit-Queue: Hal Canary <halcanary@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Fixes:
- create temp api for android to pass nullptr
- don't release and access sk_sp<SkData> at the same time in parameters
This reverts commit b14131c185.
Bug: skia:
Change-Id: Ic0e4f62520ba9f35455499ed30d306ad19d998a8
Reviewed-on: https://skia-review.googlesource.com/11129
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: Matt Sarett <msarett@google.com>
This reverts commit 9920b10f52.
Reason for revert: trying to get details on w2k failure
https://chromium-swarm.appspot.com/task?id=354345d34ba3b310&refresh=10
Caught exception 3221225477 EXCEPTION_ACCESS_VIOLATION, was running:
unit test HugeBlurImageFilter
unit test FontNames
unit test Codec_PngRoundTrip
unit test ClampRange
unit test FontHost
unit test ColorMatrixFilter
f16 image scaled_codec_premul abnormal.wbmp
565 image brd_android_codec_divisor_0.167 interlaced3.png_0.167
unit test Codec_png
unit test ImageFilterBlurLargeImage
unit test FontObj
unit test DrawText
unit test GrShape
565 image brd_android_codec_divisor_0.333 interlaced2.png_0.333
unit test PathOpsOpCubicsThreaded
unit test PathOpsOpLoopsThreaded
unit test FontMgr
unit test ColorToHSVRoundTrip
unit test Image_Serialize_Encoding_Failure
Likely culprit:
unit test Image_Serialize_Encoding_Failure
step returned non-zero exit code: -1073741819
Original change's description:
> Revert[2] "clean up (partially) colortable api""
>
> This reverts commit 1d1165ca65.
>
> Bug: skia:
> Change-Id: Idbc0634ae3cec2e79f592d252de8751b077e6408
> Reviewed-on: https://skia-review.googlesource.com/11024
> Reviewed-by: Mike Reed <reed@google.com>
> Commit-Queue: Mike Reed <reed@google.com>
>
TBR=reed@google.com,reviews@skia.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: Ia4e73434b083224baa36092c69526c2f59bb16aa
Reviewed-on: https://skia-review.googlesource.com/11025
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Reed <reed@google.com>
This reverts commit 2e491a6a11.
Reason for revert: Windows unit tests failing?
Original change's description:
> clean up (partially) colortable api
>
> Needs this to land: https://codereview.chromium.org/2789853002/
>
> Bug: skia:
> Change-Id: I38d916a546b7fa64d000d973e695ddda24a589e7
> Reviewed-on: https://skia-review.googlesource.com/10600
> Commit-Queue: Mike Reed <reed@google.com>
> Reviewed-by: Matt Sarett <msarett@google.com>
>
TBR=msarett@google.com,scroggo@google.com,reed@google.com,reviews@skia.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: I626e7edfcea82576a440dcaa851a04cedee6233f
Reviewed-on: https://skia-review.googlesource.com/10966
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Allow evaluation choice of Lazy or Eager evaluation for SkDeferredCanvas.
Eager is used for drawing to a non-recording canvas to reduce the number of
all operations.
Lazy is used for drawing to a recording canvas to reduce the amount decode/encode
that happens.
R=reed@google.com
Change-Id: I7837c4f6e5911c153e0796162e1170edbc34839e
Reviewed-on: https://skia-review.googlesource.com/9839
Commit-Queue: Herb Derby <herb@google.com>
Reviewed-by: Mike Reed <reed@google.com>
This reverts commit 73e21af213.
Reason for revert: I will fix the broken bot next week.
Original change's description:
> Revert "Add color spin test for SkColorSpaceXformCanvas"
>
> This reverts commit cb01aec63b.
>
> Reason for revert: Breaks Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Debug-SK_USE_DISCARDABLE_SCALEDIMAGECACHE
>
> Original change's description:
> > Add color spin test for SkColorSpaceXformCanvas
> >
> > Also changes behavior to treat nullptr srcs as sRGB.
> >
> > Testing locally, it looks like 353 gms have no diffs from 8888.
> > There are 269 diffs - some are fine (gms that do color space stuff)
> > and some are bugs.
> >
> > BUG=skia:
> >
> > Change-Id: I55c2825f4f4b857e0b0a0ec050c6db82ac881492
> > Reviewed-on: https://skia-review.googlesource.com/9738
> > Reviewed-by: Brian Osman <brianosman@google.com>
> > Commit-Queue: Matt Sarett <msarett@google.com>
> >
>
> TBR=mtklein@google.com,msarett@google.com,brianosman@google.com,reviews@skia.org
> # Not skipping CQ checks because original CL landed > 1 day ago.
> BUG=skia:
>
> Change-Id: I70bb69f747b863d267494e37a60888a51ab0184c
> Reviewed-on: https://skia-review.googlesource.com/9823
> Reviewed-by: Eric Boren <borenet@google.com>
> Commit-Queue: Eric Boren <borenet@google.com>
>
TBR=borenet@google.com,mtklein@google.com,msarett@google.com,reviews@skia.org,brianosman@google.com
# Not skipping CQ checks because original CL landed > 1 day ago.
BUG=skia:
Change-Id: I766382e6655f614042cded84f547f9fd5b109fca
Reviewed-on: https://skia-review.googlesource.com/9879
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
This reverts commit cb01aec63b.
Reason for revert: Breaks Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Debug-SK_USE_DISCARDABLE_SCALEDIMAGECACHE
Original change's description:
> Add color spin test for SkColorSpaceXformCanvas
>
> Also changes behavior to treat nullptr srcs as sRGB.
>
> Testing locally, it looks like 353 gms have no diffs from 8888.
> There are 269 diffs - some are fine (gms that do color space stuff)
> and some are bugs.
>
> BUG=skia:
>
> Change-Id: I55c2825f4f4b857e0b0a0ec050c6db82ac881492
> Reviewed-on: https://skia-review.googlesource.com/9738
> Reviewed-by: Brian Osman <brianosman@google.com>
> Commit-Queue: Matt Sarett <msarett@google.com>
>
TBR=mtklein@google.com,msarett@google.com,brianosman@google.com,reviews@skia.org
# Not skipping CQ checks because original CL landed > 1 day ago.
BUG=skia:
Change-Id: I70bb69f747b863d267494e37a60888a51ab0184c
Reviewed-on: https://skia-review.googlesource.com/9823
Reviewed-by: Eric Boren <borenet@google.com>
Commit-Queue: Eric Boren <borenet@google.com>
Also changes behavior to treat nullptr srcs as sRGB.
Testing locally, it looks like 353 gms have no diffs from 8888.
There are 269 diffs - some are fine (gms that do color space stuff)
and some are bugs.
BUG=skia:
Change-Id: I55c2825f4f4b857e0b0a0ec050c6db82ac881492
Reviewed-on: https://skia-review.googlesource.com/9738
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Matt Sarett <msarett@google.com>
TODO:
images
shaders
color filters
image filters
a couple stray color arrays
Change-Id: Ib91639bb0a6a00af737dd5186180011fe5120860
Reviewed-on: https://skia-review.googlesource.com/9529
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
This should fix flakiness on the Win 2k8 bots.
BUG=skia:
Change-Id: Ibdd33279a092172f0b154493f59790a8db9f58bd
Reviewed-on: https://skia-review.googlesource.com/9142
Reviewed-by: Leon Scroggins <scroggo@google.com>
Reviewed-by: Cary Clark <caryclark@google.com>
Commit-Queue: Matt Sarett <msarett@google.com>
Change-Id: Ieaa849bceba0e98e4c99491c721fe945a0694e68
Reviewed-on: https://skia-review.googlesource.com/9111
Reviewed-by: Mike Klein <mtklein@chromium.org>
Reviewed-by: Herb Derby <herb@google.com>
Reviewed-by: Stan Iliev <stani@google.com>
Commit-Queue: Derek Sollenberger <djsollen@google.com>
Also changes the behavior of these flags to only override their
corresponding context options when set, and to leave them unchanged
when not set.
BUG=skia:
Change-Id: I09f6be09997594fa888d9045dd4901354ef3f880
Reviewed-on: https://skia-review.googlesource.com/8780
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Chris Dalton <csmartdalton@google.com>
BUG=skia:
Change-Id: I4bc11042dd1dbf1eabd40af206027bc65acc3186
Reviewed-on: https://skia-review.googlesource.com/8444
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: Matt Sarett <msarett@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
BUG=skia:
Change-Id: I01c5e1874c9a034febc64e25b3aaafb5050393a6
Reviewed-on: https://skia-review.googlesource.com/8021
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Matt Sarett <msarett@google.com>
Now requires a IXpsOMObjectFactory pointer. This will allow sandboxing
to be used in Chromium. (Chrome will create a IXpsOMObjectFactory, then
go into sandbox mode, then call SkDocumenent::MakeXPS().)
Change-Id: Ic4b48d4b148c44e188d12a9481fb74735546528a
Reviewed-on: https://skia-review.googlesource.com/8052
Reviewed-by: Ben Wagner <bungeman@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Hal Canary <halcanary@google.com>
A later CL will move all document-level fields and methods into
SkXPSDocument.
* SkXPSDocument cnstructor requires a xps factory ptr.
* All device layers share ownership of a single factory.
* renames SkDocument_XPS to the easier-to-say SkXPSDocument.
* Moves autocoinitialize to DM.
TODO: pipe the IXpsOMObjectFactory* into the SkDocument api.
No change in rendered documents.
Change-Id: I8a4680a3603951b1ce5f6c1de48714d4902061a9
Reviewed-on: https://skia-review.googlesource.com/7998
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Hal Canary <halcanary@google.com>
Testing premul f16 is enough test coverage, and we aren't doing
this correctly right now anyways (the drawing code assumes a
premul bitmap, we would need to premultiply after the unpremul
decode).
BUG=skia:
Change-Id: I798f56db67faadd0348974453a05cd726b9a509c
Reviewed-on: https://skia-review.googlesource.com/8020
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Matt Sarett <msarett@google.com>
I've only been running F16 tests in "colorImage" mode.
We really should be running our "image" tests to F16 as well - so
they can be tested with scaling, subsets, etc.
This CL fixes bugs so that we can enable those tests.
BUG=skia:
Change-Id: I8137eb4fce7ea12f2c9d233a029d946d4a63e6b0
Reviewed-on: https://skia-review.googlesource.com/7801
Commit-Queue: Matt Sarett <msarett@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
* SkAutoFree moved to SkTemplates.h (now implmented with unique_ptr).
* SkAutoMalloc and SkAutoSMalloc moved to SkAutoMalloc.h
* "SkAutoFree X(sk_malloc_throw(N));" --> "SkAutoMalloc X(N);"
Revert "Revert 'SkTypes.h : move SkAutoMalloc into SkAutoMalloc.h'"
This reverts commit c456b73fef.
Change-Id: Ie2c1a17c20134b8ceab85a68b3ae3e61c24fbaab
Reviewed-on: https://skia-review.googlesource.com/6886
Reviewed-by: Hal Canary <halcanary@google.com>
Commit-Queue: Hal Canary <halcanary@google.com>
* SkAutoFree moved to SkTemplates.h (now implmented with unique_ptr).
* SkAutoMalloc and SkAutoSMalloc moved to SkAutoMalloc.h
* "SkAutoFree X(sk_malloc_throw(N));" --> "SkAutoMalloc X(N);"
Change-Id: Idacd86ca09e22bf092422228599ae0d9bedded88
Reviewed-on: https://skia-review.googlesource.com/4543
Reviewed-by: Ben Wagner <bungeman@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Hal Canary <halcanary@google.com>
Change-Id: I80f951976558a284e55386e0a368f08bd835d8ca
Reviewed-on: https://skia-review.googlesource.com/6359
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Before my recent CL, these were not run at all (because the decode
color type was gray and the bitmap color type was alpha).
https://skia-review.googlesource.com/c/6088/
Now that these are being run, we should mark the bitmap as
gray so they draw correctly.
BUG=skia:
Change-Id: I9bdfe97671a60da2bcbef55377e1c1b2bd326f8f
Reviewed-on: https://skia-review.googlesource.com/6160
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Matt Sarett <msarett@google.com>
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>
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>
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>
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
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>
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
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
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
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
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
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
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
- 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
Add extended config specification form that can be used to run different
gpu backend with different APIs.
The configs can be specified with the form:
gpu(api=string,dit=bool,nvpr=bool,samples=int)
This replaces and removes the --gpuAPI flag.
All existing configs should still work.
Adds following documentation:
out/Debug/dm --help config
Flags:
--config: type: string default: 565 8888 gpu nonrendering
Options: 565 8888 debug gpu gpudebug gpudft gpunull msaa16 msaa4
nonrendering null nullgpu nvprmsaa16 nvprmsaa4 pdf pdf_poppler skp svg
xps or use extended form 'backend(option=value,...)'.
Extended form: 'backend(option=value,...)'
Possible backends and options:
gpu(api=string,dit=bool,nvpr=bool,samples=int) GPU backend
api type: string default: native.
Select graphics API to use with gpu backend.
Options:
native Use platform default OpenGL or OpenGL ES backend.
gl Use OpenGL.
gles Use OpenGL ES.
debug Use debug OpenGL.
null Use null OpenGL.
dit type: bool default: false.
Use device independent text.
nvpr type: bool default: false.
Use NV_path_rendering OpenGL and OpenGL ES extension.
samples type: int default: 0.
Use multisampling with N samples.
Predefined configs:
gpu = gpu()
msaa4 = gpu(samples=4)
msaa16 = gpu(samples=16)
nvprmsaa4 = gpu(nvpr=true,samples=4)
nvprmsaa16 = gpu(nvpr=true,samples=16)
gpudft = gpu(dit=true)
gpudebug = gpu(api=debug)
gpunull = gpu(api=null)
debug = gpu(api=debug)
nullgpu = gpu(api=null)
BUG=skia:2992
Committed: https://skia.googlesource.com/skia/+/e13ca329fca4c28cf4e078561f591ab27b743d23
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1490113005
Committed: https://skia.googlesource.com/skia/+/c8b4336444e7b90382e04e33665fb3b8490b825b
Committed: https://skia.googlesource.com/skia/+/9ebc3f0ee6db215dde461dc4777d85988cf272dd
Review URL: https://codereview.chromium.org/1490113005
Add extended config specification form that can be used to run different
gpu backend with different APIs.
The configs can be specified with the form:
gpu(api=string,dit=bool,nvpr=bool,samples=int)
This replaces and removes the --gpuAPI flag.
All existing configs should still work.
Adds following documentation:
out/Debug/dm --help config
Flags:
--config: type: string default: 565 8888 gpu nonrendering
Options: 565 8888 debug gpu gpudebug gpudft gpunull msaa16 msaa4
nonrendering null nullgpu nvprmsaa16 nvprmsaa4 pdf pdf_poppler skp svg
xps or use extended form 'backend(option=value,...)'.
Extended form: 'backend(option=value,...)'
Possible backends and options:
gpu(api=string,dit=bool,nvpr=bool,samples=int) GPU backend
api type: string default: native.
Select graphics API to use with gpu backend.
Options:
native Use platform default OpenGL or OpenGL ES backend.
gl Use OpenGL.
gles Use OpenGL ES.
debug Use debug OpenGL.
null Use null OpenGL.
dit type: bool default: false.
Use device independent text.
nvpr type: bool default: false.
Use NV_path_rendering OpenGL and OpenGL ES extension.
samples type: int default: 0.
Use multisampling with N samples.
Predefined configs:
gpu = gpu()
msaa4 = gpu(samples=4)
msaa16 = gpu(samples=16)
nvprmsaa4 = gpu(nvpr=true,samples=4)
nvprmsaa16 = gpu(nvpr=true,samples=16)
gpudft = gpu(dit=true)
gpudebug = gpu(api=debug)
gpunull = gpu(api=null)
debug = gpu(api=debug)
nullgpu = gpu(api=null)
BUG=skia:2992
Committed: https://skia.googlesource.com/skia/+/e13ca329fca4c28cf4e078561f591ab27b743d23
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1490113005
Committed: https://skia.googlesource.com/skia/+/c8b4336444e7b90382e04e33665fb3b8490b825b
Review URL: https://codereview.chromium.org/1490113005
Reason for revert:
This CL changed 1200 images on gold, when I wouldn't expect any diffs from the description.
Original issue's description:
> Add config options to run different GPU APIs to dm and nanobench
>
> Add extended config specification form that can be used to run different
> gpu backend with different APIs.
>
> The configs can be specified with the form:
> gpu(api=string,dit=bool,nvpr=bool,samples=int)
>
> This replaces and removes the --gpuAPI flag.
>
> All existing configs should still work.
>
> Adds following documentation:
>
> out/Debug/dm --help config
>
> Flags:
> --config: type: string default: 565 8888 gpu nonrendering
> Options: 565 8888 debug gpu gpudebug gpudft gpunull msaa16 msaa4
> nonrendering null nullgpu nvprmsaa16 nvprmsaa4 pdf pdf_poppler skp svg
> xps or use extended form 'backend(option=value,...)'.
>
> Extended form: 'backend(option=value,...)'
>
> Possible backends and options:
>
> gpu(api=string,dit=bool,nvpr=bool,samples=int) GPU backend
> api type: string default: native.
> Select graphics API to use with gpu backend.
> Options:
> native Use platform default OpenGL or OpenGL ES backend.
> gl Use OpenGL.
> gles Use OpenGL ES.
> debug Use debug OpenGL.
> null Use null OpenGL.
> dit type: bool default: false.
> Use device independent text.
> nvpr type: bool default: false.
> Use NV_path_rendering OpenGL and OpenGL ES extension.
> samples type: int default: 0.
> Use multisampling with N samples.
>
> Predefined configs:
>
> gpu = gpu()
> msaa4 = gpu(samples=4)
> msaa16 = gpu(samples=16)
> nvprmsaa4 = gpu(nvpr=true,samples=4)
> nvprmsaa16 = gpu(nvpr=true,samples=16)
> gpudft = gpu(dit=true)
> gpudebug = gpu(api=debug)
> gpunull = gpu(api=null)
> debug = gpu(api=debug)
> nullgpu = gpu(api=null)
>
> BUG=skia:2992
>
> Committed: https://skia.googlesource.com/skia/+/e13ca329fca4c28cf4e078561f591ab27b743d23
> GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1490113005
>
> Committed: https://skia.googlesource.com/skia/+/c8b4336444e7b90382e04e33665fb3b8490b825bTBR=mtklein@google.com,bsalomon@google.com,scroggo@google.com,kkinnunen@nvidia.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:2992
Review URL: https://codereview.chromium.org/1536963002
Add extended config specification form that can be used to run different
gpu backend with different APIs.
The configs can be specified with the form:
gpu(api=string,dit=bool,nvpr=bool,samples=int)
This replaces and removes the --gpuAPI flag.
All existing configs should still work.
Adds following documentation:
out/Debug/dm --help config
Flags:
--config: type: string default: 565 8888 gpu nonrendering
Options: 565 8888 debug gpu gpudebug gpudft gpunull msaa16 msaa4
nonrendering null nullgpu nvprmsaa16 nvprmsaa4 pdf pdf_poppler skp svg
xps or use extended form 'backend(option=value,...)'.
Extended form: 'backend(option=value,...)'
Possible backends and options:
gpu(api=string,dit=bool,nvpr=bool,samples=int) GPU backend
api type: string default: native.
Select graphics API to use with gpu backend.
Options:
native Use platform default OpenGL or OpenGL ES backend.
gl Use OpenGL.
gles Use OpenGL ES.
debug Use debug OpenGL.
null Use null OpenGL.
dit type: bool default: false.
Use device independent text.
nvpr type: bool default: false.
Use NV_path_rendering OpenGL and OpenGL ES extension.
samples type: int default: 0.
Use multisampling with N samples.
Predefined configs:
gpu = gpu()
msaa4 = gpu(samples=4)
msaa16 = gpu(samples=16)
nvprmsaa4 = gpu(nvpr=true,samples=4)
nvprmsaa16 = gpu(nvpr=true,samples=16)
gpudft = gpu(dit=true)
gpudebug = gpu(api=debug)
gpunull = gpu(api=null)
debug = gpu(api=debug)
nullgpu = gpu(api=null)
BUG=skia:2992
Committed: https://skia.googlesource.com/skia/+/e13ca329fca4c28cf4e078561f591ab27b743d23
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1490113005
Review URL: https://codereview.chromium.org/1490113005
Reason for revert:
speculative revert to see if it unblocks the DEPS roll
https://codereview.chromium.org/1529443002
Original issue's description:
> Add config options to run different GPU APIs to dm and nanobench
>
> Add extended config specification form that can be used to run different
> gpu backend with different APIs.
>
> The configs can be specified with the form:
> gpu(api=string,dit=bool,nvpr=bool,samples=int)
>
> This replaces and removes the --gpuAPI flag.
>
> All existing configs should still work.
>
> Adds following documentation:
>
> out/Debug/dm --help config
>
> Flags:
> --config: type: string default: 565 8888 gpu nonrendering
> Options: 565 8888 debug gpu gpudebug gpudft gpunull msaa16 msaa4
> nonrendering null nullgpu nvprmsaa16 nvprmsaa4 pdf pdf_poppler skp svg
> xps or use extended form 'backend(option=value,...)'.
>
> Extended form: 'backend(option=value,...)'
>
> Possible backends and options:
>
> gpu(api=string,dit=bool,nvpr=bool,samples=int) GPU backend
> api type: string default: native.
> Select graphics API to use with gpu backend.
> Options:
> native Use platform default OpenGL or OpenGL ES backend.
> gl Use OpenGL.
> gles Use OpenGL ES.
> debug Use debug OpenGL.
> null Use null OpenGL.
> dit type: bool default: false.
> Use device independent text.
> nvpr type: bool default: false.
> Use NV_path_rendering OpenGL and OpenGL ES extension.
> samples type: int default: 0.
> Use multisampling with N samples.
>
> Predefined configs:
>
> gpu = gpu()
> msaa4 = gpu(samples=4)
> msaa16 = gpu(samples=16)
> nvprmsaa4 = gpu(nvpr=true,samples=4)
> nvprmsaa16 = gpu(nvpr=true,samples=16)
> gpudft = gpu(dit=true)
> gpudebug = gpu(api=debug)
> gpunull = gpu(api=null)
> debug = gpu(api=debug)
> nullgpu = gpu(api=null)
>
> BUG=skia:2992
>
> Committed: https://skia.googlesource.com/skia/+/e13ca329fca4c28cf4e078561f591ab27b743d23TBR=bsalomon@google.com,scroggo@google.com,joshualitt@google.com,kkinnunen@nvidia.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:2992
Review URL: https://codereview.chromium.org/1528473002
Add extended config specification form that can be used to run different
gpu backend with different APIs.
The configs can be specified with the form:
gpu(api=string,dit=bool,nvpr=bool,samples=int)
This replaces and removes the --gpuAPI flag.
All existing configs should still work.
Adds following documentation:
out/Debug/dm --help config
Flags:
--config: type: string default: 565 8888 gpu nonrendering
Options: 565 8888 debug gpu gpudebug gpudft gpunull msaa16 msaa4
nonrendering null nullgpu nvprmsaa16 nvprmsaa4 pdf pdf_poppler skp svg
xps or use extended form 'backend(option=value,...)'.
Extended form: 'backend(option=value,...)'
Possible backends and options:
gpu(api=string,dit=bool,nvpr=bool,samples=int) GPU backend
api type: string default: native.
Select graphics API to use with gpu backend.
Options:
native Use platform default OpenGL or OpenGL ES backend.
gl Use OpenGL.
gles Use OpenGL ES.
debug Use debug OpenGL.
null Use null OpenGL.
dit type: bool default: false.
Use device independent text.
nvpr type: bool default: false.
Use NV_path_rendering OpenGL and OpenGL ES extension.
samples type: int default: 0.
Use multisampling with N samples.
Predefined configs:
gpu = gpu()
msaa4 = gpu(samples=4)
msaa16 = gpu(samples=16)
nvprmsaa4 = gpu(nvpr=true,samples=4)
nvprmsaa16 = gpu(nvpr=true,samples=16)
gpudft = gpu(dit=true)
gpudebug = gpu(api=debug)
gpunull = gpu(api=null)
debug = gpu(api=debug)
nullgpu = gpu(api=null)
BUG=skia:2992
Review URL: https://codereview.chromium.org/1490113005
This should fix some odd formatting problems in the logs, e.g.
Note tally:
583x (skipped: Cannot convert to requested color type.
)
4x (--blacklist _ image decode 4bpp-pixeldata-cropped.bmp)
~~~>
Note tally:
583x (skipped: Cannot convert to requested color type.)
4x (--blacklist _ image decode 4bpp-pixeldata-cropped.bmp)
BUG=skia:
Review URL: https://codereview.chromium.org/1508223006
Reason for revert:
BUG=skia:4609
skbug.com/4609
Seems like GrContextFactory needs to fail when the NVPR option is requested but the driver version isn't sufficiently high.
Original issue's description:
> Make NVPR a GL context option instead of a GL context
>
> Make NVPR a GL context option instead of a GL context.
> This may enable NVPR to be run with command buffer
> interface.
>
> No functionality change in DM or nanobench. NVPR can
> only be run with normal GL APIs.
>
> BUG=skia:2992
>
> Committed: https://skia.googlesource.com/skia/+/eeebdb538d476c1bfc8b63a946094ca1b505ecd1TBR=mtklein@google.com,jvanverth@google.com,kkinnunen@nvidia.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:2992
Review URL: https://codereview.chromium.org/1486153002
Make NVPR a GL context option instead of a GL context.
This may enable NVPR to be run with command buffer
interface.
No functionality change in DM or nanobench. NVPR can
only be run with normal GL APIs.
BUG=skia:2992
Review URL: https://codereview.chromium.org/1448883002
Rename SkCodecTools.h to SkBitmapRegionDecoderPriv.h
Move BRD code to its own directory in tools. This
allows us to not need to expose the entire tools
directory in Android.
BUG=skia:
Review URL: https://codereview.chromium.org/1417393004
We no longer need to worry about namespace
conflicts SkBitmapRegionDecoder in Android (which
we are replacing).
Additionally, the static Create() function does not
need to repeat the name BitmapRegionDecoder.
BUG=skia:
Review URL: https://codereview.chromium.org/1415243007
Remove double negative.
Also, change another error message to be slightly (meaningfully)
different so I can find the right one based on the log.
Review URL: https://codereview.chromium.org/1424083004
This involves disabling webps for kCanvas_Strategy.
We have not yet implemented webp subset decodes for this
strategy.
BUG=skia:4521
Review URL: https://codereview.chromium.org/1405273004
The result SkBitmap, the pixel allocator, and the alpha
preference need to be communicated from the client to
the region decoder.
BUG=skia:
Review URL: https://codereview.chromium.org/1418093006
Turns out bitmap.eraseColor() does nothing if the bitmap
is kIndex8. We need a more reliable way to initialize
all of the pixels that we look at in Gold.
The input SkCanvas* is always zero initialized, so let's
only draw pixels to the canvas if we have initialized them.
BUG=skia:
Review URL: https://codereview.chromium.org/1418913002
We will implement this API using SkCodecs.
SkAndroidCodecs will be used to implement the
BitmapRegionDecoder Java API (and possibly
BitmapFactory).
BUG=skia:
Review URL: https://codereview.chromium.org/1406223002
This CL allows the SkScanlineDecoder to decode partial
scanlines.
This is a first step in efficiently implementing subsetting
in SkScaledCodec.
BUG=skia:4209
Review URL: https://codereview.chromium.org/1390213002
Use SkCodecPrintf instead of SkDebugf.
Check if the conversion is possible rather than starting many decodes
that will certainly fail.
Small refactor to code that deals with subsets that fall outside
of the image.
BUG=skia:
Review URL: https://codereview.chromium.org/1395383002
Rather than implementing some sort of "fill" in every
SkCodec subclass for incomplete images, let's make the
parent class handle this situation.
This includes an API change to SkCodec.h
SkCodec::getScanlines() now returns the number of lines it
read successfully, rather than an SkCodec::Result enum.
getScanlines() most often fails on an incomplete input, in
which case it is useful to know how many lines were
successfully decoded - this provides more information than
kIncomplete vs kSuccess. We do lose information when the
API is used improperly, as we are no longer able to return
kInvalidParameter or kScanlineNotStarted.
Known Issues:
Does not work for incomplete fFrameIsSubset gifs.
Does not work for incomplete icos.
BUG=skia:
Review URL: https://codereview.chromium.org/1332053002
Looking in Gold, I see some ICO images that only show the upper left
corner of the originals. It is happening because we use different ways
of deciding what the dimensions are:
In CodecSrc::size(), we use an SkScaledCodec to get the dimensions,
even when fMode is not kScaledCodec_Mode.
In CodecSrc::draw(), we only use SkScaledCodec in kScaledCodec_Mode.
My recent CL to combine SkScanlineDecoder with SkCodec revealed this
bug, because now SkScaledCodec::NewFromStream will succeed on ICO.
(Previously, it failed because we do not yet have a scanline decoder
for ICO (skbug.com/4404). Now that they are combined, we would need
to specially flag ICO to stop returning an SkScaledCodec.)
Switch size() to use the correct type of codec.
Review URL: https://codereview.chromium.org/1373253004
Benefits:
- This mimics other decoding APIs (including the ones SkCodec relies
on, e.g. a png_struct, which can be used to decode an entire image or
one line at a time).
- It allows a client to ask us to do what we can do efficiently - i.e.
start from encoded data and either decode the whole thing or scanlines.
- It removes the duplicate methods which appeared in both SkCodec and
SkScanlineDecoder (some of which, e.g. in SkJpegScanlineDecoder, just
call fCodec->sameMethod()).
- It simplifies moving more checks into the base class (e.g. the
examples in skbug.com/4284).
BUG=skia:4175
BUG=skia:4284
=====================================================================
SkScanlineDecoder.h/.cpp:
Removed.
SkCodec.h/.cpp:
Add methods, enums, and variables which were previously in
SkScanlineDecoder.
Default fCurrScanline to -1, as a sentinel that start has not been
called.
General changes:
Convert SkScanlineDecoders to SkCodecs.
General changes in SkCodec subclasses:
Merge SkScanlineDecoder implementation into SkCodec. Most (all?) owned
an SkCodec, so they now call this-> instead of fCodec->.
SkBmpCodec.h/.cpp:
Replace the unused rowOrder method with an override for
onGetScanlineOrder.
Make getDstRow const, since it is called by onGetY, which is const.
SkCodec_libpng.h/.cpp:
Make SkPngCodec an abstract class, with two subclasses which handle
scanline decoding separately (they share code for decoding the entire
image). Reimplement onReallyHasAlpha so that it can return the most
recent result (e.g. after a scanline decode which only decoded part
of the image) or a better answer (e.g. if the whole image is known to
be opaque).
Compute fNumberPasses early, so we know which subclass to instantiate.
Make SkPngInterlaceScanlineDecoder use the base class' fCurrScanline
rather than a separate variable.
CodexTest.cpp:
Add tests for the state changes in SkCodec (need to call start before
decoding scanlines; calling getPixels means that start will need to
be called again before decoding more scanlines).
Add a test which decodes in stripes, currently only used for an
interlaced PNG.
TODO: Add tests for onReallyHasAlpha.
Review URL: https://codereview.chromium.org/1365313002
- use C++11 features ({} init, move constructors) to eliminate the need
for explicit constructors
- collapse RECORD0...RECORD8 into just one RECORD macro
- explicitly tag record types instead of using member detectors.
Removing member detectors makes this code significantly less fragile.
This exposes a few places where we didn't really think through what to do
with SkDrawable. I've marked them TODO for now.
BUG=skia:
Review URL: https://codereview.chromium.org/1360943003
Motivation: I want too finalize this API before working on the more
complex problem of adding XMP metadata for PDF/A.
BUG=skia:3110
Review URL: https://codereview.chromium.org/1359943003
SkBitmapRegionDecoderInterface provides an interface
for multiple implementations of Android's
BitmapRegionDecoder.
We already have correctness tests in DM that will enable us
to compare the quality of our various BRD implementations.
We also need these performance tests to compare the speed
of our various implementations.
BUG=skia:4357
Review URL: https://codereview.chromium.org/1344993003
*** Add CodecMode and ScaledCodecMode (in place of
NormalMode), so now we test SkCodec's getPixels() and
SkScaledCodec's getPixels()
*** Don't attempt to test scanline and codec modes using
the dimensions that were recommended for SkScaledCodec.
*** Change tags so that each scale gets its own output
folder.
TODO: Make ScanlineMode and ScanlineSubsetMode support
kOutOfOrder etc. I think this belongs with the gif CL -
I don't want to add test modes that we don't run yet.
BUG=skia:4202
BUG=skia:4238
Review URL: https://codereview.chromium.org/1327433003
Redesigns SkScanlineDecoder.h to indicate the ordering
in which the scanlines are provided
Refactors SkSwizzler::Fill() to include the zeroInit check
and to actually be correct.
BUG=skia:3257
BUG=skia:4198
Review URL: https://codereview.chromium.org/1287423002
We don't want to test small images on Gold because they are
not interested to look at. Instead, I wrote a unit test to
verify that scaling small images does not cause crashes.
BUG=skia:
Review URL: https://codereview.chromium.org/1287863004
Prior to this CL, if a client wanted to decode scanlines, they had to
create an SkCodec in order to get an SkScanlineDecoder. This introduces
complications if input data is not easily shared between the two
objects.
Instead, add methods to SkScanlineDecoder for creating a new one from
input data, and remove the creation functions from SkCodec.
Update DM and tests.
Review URL: https://codereview.chromium.org/1267583002
The decoding tests can now veto indirect sinks like pipe-8888.
This moves Sink type detection from automatic to explicit; I can't think of any
way to automatically differentiate pipe-8888 from 8888 based only on the
output. (They should ideally be identical, after all.)
BUG=skia:4138
Review URL: https://codereview.chromium.org/1263113002
In CodecSrc's scanline_subset test, we decode a subset of an image to a
bitmap, draw it to the canvas, and then repeat. This is fine for most
backends, but not for pipe. Pipe sees the same generation ID, so it
assumes it is the same bitmap it saw before, and just draws the
original one.
Call notifyPixelsChanged, so the bitmap will get a new generation ID,
fixing pipe.
BUG=skia:4138
Review URL: https://codereview.chromium.org/1265983004
This breaks Sinks down into three auto-detected types:
- GPU: anything that requests to be run in the GPU enclave
- Vector: anything that writes to the stream instead of the bitmap
- Raster: everything else
Some examples: gpu -> GPU, msaa16 -> GPU, 8888 -> raster, pdf -> vector,
svg -> vector, pipe-8888 -> raster, tiles_rt-gpu -> GPU
This lets image decoding sinks veto non-raster backends explicitly,
and can let particular GMs veto GPU or non-GPU sinks as they like.
BUG=skia:
Review URL: https://codereview.chromium.org/1239953004
This allows codecs that support subsets natively (i.e. WEBP) to do so.
Add a field on SkCodec::Options representing the subset.
Add a method on SkCodec to find a valid subset which approximately
matches a desired subset.
Implement subset decodes in SkWebpCodec.
Add a test in DM for decoding subsets.
Notice that we only start on even boundaries. This is due to the
way libwebp's API works. SkWEBPImageDecoder does not take this into
account, which results in visual artifacts.
FIXME: Subsets with scaling are not pixel identical, but close. (This
may be fine, though - they are not perceptually different. We'll just
need to mark another set of images in gold as valid, once
https://skbug.com/4038 is fixed, so we can tests scaled webp without
generating new images on each run.)
Review URL: https://codereview.chromium.org/1240143002
Make getScanlineDecoder return a new object each time, which is
owned by the caller, and independent from any existing scanline
decoders and the SkCodec itself.
Since the SkCodec already contains the entire state machine, and it
is used by the scanline decoders, simply create a new SkCodec which
is now owned by the scanline decoder.
Move code that cleans up after using a scanline decoder into its
destructor
One side effect is that creating the first scanline decoder requires
a duplication of the stream and re-reading the header. (With some
more complexity/changes, we could pass the state machine to the
scanline decoder and make the SkCodec recreate its own state machine
instead.) The typical client of the scanline decoder (region decoder)
uses an SkMemoryStream, so the duplication is cheap, although we
should consider the extra time to reread the header/recreate the state
machine. (If/when we use the scanline decoder for other purposes,
where the stream may not be cheaply duplicated, we should consider
passing the state machine.)
One (intended) result of this change is that a client can create a
new scanline decoder in a new thread, and decode different pieces of
the image simultaneously.
In SkPngCodec::decodePalette, use fBitDepth rather than a parameter.
Review URL: https://codereview.chromium.org/1230033004
SkImageGenerator makes some assumptions that are not necessarily valid
for SkCodec. For example, SkCodec does not assume that it can always be
rewound.
We also have an ongoing question of what an SkCodec should report as
its default settings (i.e. the return from getInfo). It makes sense for
an SkCodec to report that its pixels are unpremultiplied, if that is
the case for the underlying data, but if a client of SkImageGenerator
uses the default settings (as many do), they will receive
unpremultiplied pixels which cannot (currently) be drawn with Skia. We
may ultimately decide to revisit SkCodec reporting an SkImageInfo, but
I have left it unchanged for now.
Import features of SkImageGenerator used by SkCodec into SkCodec.
I have left SkImageGenerator unchanged for now, but it no longer needs
Result or Options. This will require changes to Chromium.
Manually handle the lifetime of fScanlineDecoder, so SkScanlineDecoder.h
can include SkCodec.h (where Result is), and SkCodec.h does not need
to include it (to delete fScanlineDecoder).
In many places, make the following simple changes:
- Now include SkScanlineDecoder.h, which is no longer included by
SkCodec.h
- Use the enums in SkCodec, rather than SkImageGenerator
- Stop including SkImageGenerator.h where no longer needed
Review URL: https://codereview.chromium.org/1220733013
I originally thought that there was no harm in reading or skipping
zero lines after we have already reached the end of the image.
However, once we reach the end of the image, onFinish() is
automatically called. Performing a read or a skip after
the call to onFinish() is invalid and will cause onFinish()
to be called a second time (which is also invalid).
Seems like the code requires good behavior and the test is
wrong.
BUG=skia:
Review URL: https://codereview.chromium.org/1179213002
kScanline_Subset_Mode decodes the image in subsets using a
scanline decoder.
The number of subsets can be specified by changing the constant divisor.
The number of subsets is equal to divisor*divisor.
Review URL: https://codereview.chromium.org/1157153003
Previously it was hard to tell that DrawFn took an SkCanvas* and returned an Error. Now it's clear from the type.
BUG=skia:
Review URL: https://codereview.chromium.org/1125233002
If so, let's do it this way so it works for all source types and doesn't need
to be chosen at compile time.
BUG=skia:
Review URL: https://codereview.chromium.org/1129693003
Will use this to test the other CL that adds small SkPicture implementations.
Not quite sure why patch_primitive doesn't draw the same in 8888 and sp-8888, but everything else does, so I'm not going to let that hold me back for now.
BUG=skia:
Review URL: https://codereview.chromium.org/1126613005
Enables basic decoding for jpegs
Includes rewinding
565, YUV, and Jpeg encoding are not yet implemented
BUG=skia:3257
Review URL: https://codereview.chromium.org/1076923002
Motivation: I want to switch back to single-page output by default for
direct comparison to raster backends in Gold.
I can still test the multi-page option via a command-line switch.
BUG=skia:3721
Review URL: https://codereview.chromium.org/1063873004
We may want to enable swizzles to 565
for images that are encoded in a format
similar to 565, however, we do not want
to take images that decode naturally to
kN32 and then convert them to 565.
***Enable swizzles to kIndex_8. For images
encoded in a color table format, we suggest
that they be decoded to kIndex_8. When we
decode, we only allow conversion to kIndex_8
if it matches the suggested color type (except
wbmp which seems good as is).
***Modify dm to test images that decode to
kIndex_8.
BUG=skia:3257
BUG=skia:3440
Review URL: https://codereview.chromium.org/1055743003
I'm going to start hacking on SkCanvas a bit to allow a fast reset method,
and I want to have some testing checking me.
BUG=skia:
Review URL: https://codereview.chromium.org/1062043004
@sugoi:
Early out to avoid some segfaults in SkImageDecoder_libjpeg.cpp.
I am just flailing here... things seem to work, but I have no idea why.
This prints out a lot:
libjpeg error 85 <End Of Image> from output_raw_data [0 0]
@halcanary:
I'm skipping on ImageSrc for now. Leon's refactoring that quite a lot.
This causes minor diffs for the GPU backend, given that we're now
going through the YUV path. It also reduced peak RAM usage on
my desktop from 1.26GB to 1.08GB.
BUG=skia:
Review URL: https://codereview.chromium.org/1010983004
Rather than making SkCodec an option instead of SkImageDecoder,
create a separate CodecSrc. This allows us to compare the two.
For both CodecSrc and ImageSrc, do not decode to a gpu backend.
BUG=skia:3475
Review URL: https://codereview.chromium.org/978823002
This sniffs the .skp dimensions and intersects them with our 1000x1000 viewport.
This fixes things like desk_carsvg.skp, which is only 902 pixels tall. In 565 now,
the remaining 98 pixels draw as black, which looks funny and is confusing to triage.
No apparent affect on DM memory usage. (We're about to map the file anyway.)
BUG=skia:
Review URL: https://codereview.chromium.org/986103002
Also allow incomplete to be considered successful.
Do not attempt to draw transparent images on 565.
BUG=skia:3475
Review URL: https://codereview.chromium.org/978413002
Tasks that produce a non-fatal error will bail out before writing their output to
disk and hash to dm.json, but not count as failures.
This also makes true failures bail out before writing their results. If the DM
program failed, we probably don't want to triage that image result.
We use this new feature first to skip image subset decoding when we detect it's
not supported. Here's a snippet of an example run, where in this case only
.webp are subset decodable:
...
( 15MB 12) 172µs 8888 subset color_wheel.jpg (skipped: Subset decoding not supported.)
( 15MB 11) 9.05ms 8888 subset randPixels.webp
( 16MB 10) 863µs 8888 subset baby_tux.png (skipped: Subset decoding not supported.)
...
Only outputs corresponding to the .webp show up, both on disk and in the .json.
BUG=skia:
Review URL: https://codereview.chromium.org/980333002
- SkDocument::CreateXPS() function added, returns NULL on non-Windows OS.
- DM: (Windows only) an XPSSink is added, fails on non-Windows OS
- DM: Common code for PDFSink::draw and XPSSink::draw are factored into
draw_skdocument static function.
- SkDocument_XPS (Windows only) implementation of SkDocument via
SkXPSDevice.
- SkDocument_XPS_None (non-Windows) returns NULL for
SkDocument::CreateXPS().
- gyp/xps.gyp refactored.
- SkXPSDevice::drawTextOnPath removed (see http://crrev.com/925343003 )
- SkXPSDevice::drawPath supports conics via SkAutoConicToQuads.
Review URL: https://codereview.chromium.org/963953002
DM:
Add a flag to use SkCodec instead of SkImageDecoder.
SkCodec:
Base class for codecs, allowing creation from an SkStream or an SkData.
An SkCodec, on creation, knows properties of the data like its width and height. Further calls can be used to generate the image.
TODO: Add scanline iterator
SkPngCodec:
New decoder for png. Wraps libpng. The code has been repurposed from SkImageDecoder_libpng.
TODO: Handle other destination colortypes
TODO: Substitute the transpose color
TODO: Allow silencing warnings
TODO: Use RGB instead of filler?
TODO: sRGB
SkSwizzler:
Simplified version of SkScaledSampler. Unlike the sampler, this object does no sampling.
TODO: Implement other swizzles.
Requires a gclient sync to pull down libpng.
BUG=skia:3257
Committed: https://skia.googlesource.com/skia/+/ca358852b4fed656d11107b2aaf28318a4518b49
(and then reverted)
Review URL: https://codereview.chromium.org/930283002
- SkDocument::CreateXPS() function added, returns NULL on non-Windows OS.
- DM: (Windows only) an XPSSink is added, fails on non-Windows OS
- DM: Common code for PDFSink::draw and XPSSink::draw are factored into
draw_skdocument static function.
- SkDocument_XPS (Windows only) implementation of SkDocument via
SkXPSDevice.
- SkDocument_XPS_None (non-Windows) returns NULL for
SkDocument::CreateXPS().
- gyp/xps.gyp refactored.
- SkXPSDevice::drawTextOnPath removed (see http://crrev.com/925343003 )
- SkXPSDevice::drawPath supports conics via SkAutoConicToQuads.
NOPRESUBMIT=true
Review URL: https://codereview.chromium.org/963953002
Reason for revert:
Breaking windows bots all over the place :(
Original issue's description:
> Add SkCodec, including PNG implementation.
>
> DM:
> Add a flag to use SkCodec instead of SkImageDecoder.
>
> SkCodec:
> Base class for codecs, allowing creation from an SkStream or an SkData.
> An SkCodec, on creation, knows properties of the data like its width and height. Further calls can be used to generate the image.
> TODO: Add scanline iterator
>
> SkPngCodec:
> New decoder for png. Wraps libpng. The code has been repurposed from SkImageDecoder_libpng.
> TODO: Handle other destination colortypes
> TODO: Substitute the transpose color
> TODO: Allow silencing warnings
> TODO: Use RGB instead of filler?
> TODO: sRGB
>
> SkSwizzler:
> Simplified version of SkScaledSampler. Unlike the sampler, this object does no sampling.
> TODO: Implement other swizzles.
>
> BUG=skia:3257
>
> Committed: https://skia.googlesource.com/skia/+/ca358852b4fed656d11107b2aaf28318a4518b49TBR=reed@google.com,djsollen@google.com,msarett@google.com,mtklein@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:3257
Review URL: https://codereview.chromium.org/972743003
DM:
Add a flag to use SkCodec instead of SkImageDecoder.
SkCodec:
Base class for codecs, allowing creation from an SkStream or an SkData.
An SkCodec, on creation, knows properties of the data like its width and height. Further calls can be used to generate the image.
TODO: Add scanline iterator
SkPngCodec:
New decoder for png. Wraps libpng. The code has been repurposed from SkImageDecoder_libpng.
TODO: Handle other destination colortypes
TODO: Substitute the transpose color
TODO: Allow silencing warnings
TODO: Use RGB instead of filler?
TODO: sRGB
SkSwizzler:
Simplified version of SkScaledSampler. Unlike the sampler, this object does no sampling.
TODO: Implement other swizzles.
BUG=skia:3257
Review URL: https://codereview.chromium.org/930283002
Not enabled by default, but this should get you SKPs, GMs etc for free to play with.
$ out/Debug/dm -w svgs --src gm skp --config svg
BUG=skia:
Review URL: https://codereview.chromium.org/892693002
I had some suggestions on the subset CL, and took the opportunity to rebase it
against head and merge in the other color type CL.
BUG=skia:
Review URL: https://codereview.chromium.org/893703002
This basically takes out the Windows-only hacks and promotes them to
cross-platform behavior driven by --gpu_threading.
- When --gpu_threading is false (the default), this puts GPU tasks and tests
together in the same GPU enclave. They all run serially.
- When --gpu_threading is true, both the tests and the tasks run totally
independently, just like the thread-safe CPU-bound work.
BUG=skia:3255
Review URL: https://codereview.chromium.org/847273005
SkDeferredCanvas uses a simple pipe: no cross-process, no shared-address, etc.
(see src/utils/SkDeferredCanvas.cpp:306).
We could just remove these modes from the bot configs, but I'd like to take the
opportunity to simplify the DM code too. I'll happily volunteer to put things
back should we decide we want to test these modes.
BUG=skia:
Review URL: https://codereview.chromium.org/861303003
SkStream is a stateful object, so it does not make sense for it to have
multiple owners. Make SkStream inherit directly from SkNoncopyable.
Update methods which previously called SkStream::ref() (e.g.
SkImageDecoder::buildTileIndex() and SkFrontBufferedStream::Create(),
which required the existing owners to call SkStream::unref()) to take
ownership of their SkStream parameters and delete when done (including
on failure).
Switch all SkAutoTUnref<SkStream>s to SkAutoTDelete<SkStream>s. In some
cases this means heap allocating streams that were previously stack
allocated.
Respect ownership rules of SkTypeface::CreateFromStream() and
SkImageDecoder::buildTileIndex().
Update the comments for exceptional methods which do not affect the
ownership of their SkStream parameters (e.g.
SkPicture::CreateFromStream() and SkTypeface::Deserialize()) to be
explicit about ownership.
Remove test_stream_life, which tested that buildTileIndex() behaved
correctly when SkStream was a ref counted object. The test does not
make sense now that it is not.
In SkPDFStream, remove the SkMemoryStream member. Instead of using it,
create a new SkMemoryStream to pass to fDataStream (which is now an
SkAutoTDelete).
Make other pdf rasterizers behave like SkPDFDocumentToBitmap.
SkPDFDocumentToBitmap delete the SkStream, so do the same in the
following pdf rasterizers:
SkPopplerRasterizePDF
SkNativeRasterizePDF
SkNoRasterizePDF
Requires a change to Android, which currently treats SkStreams as ref
counted objects.
Review URL: https://codereview.chromium.org/849103004
This will hold us closer to the principle that the test name (and only the test
name) should correspond to expected output. By the same reasoning, mix in the
number of subsets: if that changes, the expected output also changes.
BUG=skia:3255
Review URL: https://codereview.chromium.org/863723002
BUG=skia:3255
I think this supports everything DM used to, but has completely refactored how
it works to fit the design in the bug.
Configs like "tiles-gpu" are automatically wired up.
I wouldn't suggest looking at this as a diff. There's just a bunch of deleted
files, a few new files, and one new file that shares a name with a deleted file
(DM.cpp).
NOTREECHECKS=true
Committed: https://skia.googlesource.com/skia/+/709d2c3e5062c5b57f91273bfc11a751f5b2bb88
Review URL: https://codereview.chromium.org/788243008
Reason for revert:
plenty of data
Original issue's description:
> Sketch DM refactor.
>
> BUG=skia:3255
>
>
> I think this supports everything DM used to, but has completely refactored how
> it works to fit the design in the bug.
>
> Configs like "tiles-gpu" are automatically wired up.
>
> I wouldn't suggest looking at this as a diff. There's just a bunch of deleted
> files, a few new files, and one new file that shares a name with a deleted file
> (DM.cpp).
>
> NOTREECHECKS=true
>
> Committed: https://skia.googlesource.com/skia/+/709d2c3e5062c5b57f91273bfc11a751f5b2bb88TBR=bsalomon@google.com,mtklein@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=skia:3255
Review URL: https://codereview.chromium.org/853883004
BUG=skia:3255
I think this supports everything DM used to, but has completely refactored how
it works to fit the design in the bug.
Configs like "tiles-gpu" are automatically wired up.
I wouldn't suggest looking at this as a diff. There's just a bunch of deleted
files, a few new files, and one new file that shares a name with a deleted file
(DM.cpp).
NOTREECHECKS=true
Review URL: https://codereview.chromium.org/788243008
