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
Reason for revert:
Failures:
D/skia ( 3581): gpu image gen frame_larger_than_image.gif: Could not create a surface.
D/skia ( 3581): gpu image gen offsets_too_large.gif: Could not create a surface.
D/skia ( 3581): gpu image gen PANO_20121023_214540.jpg: Could not create a surface.
D/skia ( 3581): gpu image gen interlaced1.png: Could not create a surface.
D/skia ( 3581): gpu image gen interlaced2.png: Could not create a surface.
D/skia ( 3581): gpu image gen interlaced3.png: Could not create a surface.
D/skia ( 3581): gpu image gen Canon_5D2.dng: Could not create a surface.
D/skia ( 3581): gpu image gen Fuji_X20.dng: Could not create a surface.
D/skia ( 3581): gpu image gen HTC.dng: Could not create a surface.
D/skia ( 3581): gpu image gen lg_g4_iso_800.dng: Could not create a surface.
D/skia ( 3581): gpu image gen Canon_G7X.CR2: Could not create a surface.
D/skia ( 3581): gpu image gen Pentax_K5.DNG: Could not create a surface.
D/skia ( 3581): gpu image gen Nikon_1AW1.NEF: Could not create a surface.
D/skia ( 3581): gpu image gen Nikon_1J4.NEF: Could not create a surface.
D/skia ( 3581): gpu image gen Nikon_P330.NRW: Could not create a surface.
D/skia ( 3581): gpu image gen Olympus_E-PL3.ORF: Could not create a surface.
D/skia ( 3581): gpu image gen Olympus_PL7.ORF: Could not create a surface.
D/skia ( 3581): gpu image gen Pentax_K5.PEF: Could not create a surface.
D/skia ( 3581): gpu image gen Samsung_NX3000.SRW: Could not create a surface.
Original issue's description:
> Test CodecImageGenerator on GPU bots
>
> In crrev.com/1549473003, CodecImageGenerator implemented getYUV8Planes,
> so that we can test on a GPU bot. Update the arguments to DM so that
> we run CodecImageGenerator on GPU bots.
> GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1663453002
>
> Committed: https://skia.googlesource.com/skia/+/c9715406c4c9c995e5661a4ea2188fb8643845c0TBR=msarett@google.com,scroggo@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/1663143002
This lets us tag up pieces of code as requiring initialized inputs.
Almost all code requires initialized inputs, of course. This is for
code that works correctly with uninitialized data but triggers false
positive warnings in MSAN. E.g., imagine MSAN's found use of uninitialized
data in this max function:
static uint8_t max(uint8_t x, uint8_t y) { return x > y ? x : y; }
There's no bug in here... if there's uninitialized data being branched upon
here for the first time, it's sure not max's fault, it's its caller's fault.
So we might do this:
static uint8_t max(uint8_t x, uint8_t y) {
// This function uses branching, so if MSAN finds a problem here,
// we can assert x and y are initialized. This will remind us the
// problem somewhere in the caller or above, not here.
sk_msan_assert_initialized(&x, &x+1);
sk_masn_assert_initialized(&y, &y+1);
return x > y ? x : y;
}
By allowing code to assert its inputs must be initialized,
we can make the blame for use of uninitialized data more clear.
(Sometimes we have another option, to rewrite the code to avoid branching:
static uint8_t max(uint8_t x, uint8_t y) {
// This function is branchfree, so MSAN won't complain here.
// No real need to assert anything as requiring initialization.
int diff = x - y;
int negative = diff >> (sizeof(int)*8 - 1);
return (y & negative) | (x & ~negative);
}
These approaches to fixing MSAN false positives are orthogonal.)
BUG=chromium:574114
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1658913005
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
Review URL: https://codereview.chromium.org/1658913005
If we want to have an MSAN build, it'll help if we can build our own zlib
so that it's instrumented by MSAN.
Today we build our own zlib on Windows, but require the system to provide it
elsewhere. This just makes everyone build it (except Android framework of course).
This drops the SIMD files. They're only used to accelerate deflate
(compression), so they're not terribly interesting to us. Again, this only
really changes compression speed on Windows bots... pretty niche.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1665843002
Review URL: https://codereview.chromium.org/1665843002
Observation: filter procs are also biased by s.fFilterOne{X,Y} / 2. They all do
something along these lines:
s.fInvProc(s.fInvMatrix,
SkIntToScalar(x) + SK_ScalarHalf,
SkIntToScalar(y) + SK_ScalarHalf, &srcPt);
SkFixed fx = SkScalarToFixed(srcPt.fX) - (s.fFilterOneX >> 1);
SkFixed fy = SkScalarToFixed(srcPt.fY) - (s.fFilterOneX >> 1);
It's trivial to extend SkBitmapProcStateAutoMapper to handle this internally, and
convert everyone off explicit mapping.
R=reed@google.com
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1661613002
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
Review URL: https://codereview.chromium.org/1661613002
Bump SK_IMAGE_VERSION to test the images in v2 in GoogleStorage, which
includes the images from v1 plus test images for SkRawCodec.
Only define skia_decodes_raw on platforms that support it, rather than
defining it always and checking additional conditions to determine
whether to support raw. Further, define it and SK_CODEC_DECODES_RAW
for all targets, so we can use the compile flag in other targets.
In DM, exclude the raw extensions if SK_CODEC_DECODES_RAW is not defined.
Blacklist raw extensions on NexusPlayer, which was running out of memory
when running them.
BUG=skia:4829
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1612113002
Review URL: https://codereview.chromium.org/1612113002
You can break this CL down into three steps. Steps 2 and 3 depend on 1.
Step 1: go to a 16-bit impl. Speed ~unaffected.
Step 2: use SSSE3 16-bit abs. ~20% speedup to Paeth.
Step 3: use SSE4.1 blendv, total ~25% speedup to Paeth.
Overall this can improve PNG decoding by around 8% end-to-end.
I would feel most comfortable landing this only after we have a bot exercising the SSE4.1 code, either by moving this stuff behind a function pointer (simulating Chrome/Clank) or by adding a builder with at least SSE4.1 at compile time (simulating an Android system build). We've got plenty of bots building with SSSE3 at compile time to test that path.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dimage&master=false&issue=1657503002
Review URL: https://codereview.chromium.org/1657503002
