This is a synonym for the version of getAndroidPixels that accepts
only three parameters (i.e. no AndroidOptions). It is very similar
to SkCodec::getPixels, so I think the motivation for naming the
version with options differently does not apply here.
Add comments to the header describing defaults.
Update the test to use a template, and delete a lot of redundant code.
Rename a variable to stop shadowing another variable.
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1647153002
Review URL: https://codereview.chromium.org/1647153002
Nothing fancy here. By doing the entire conversion ourselves, we
only need to make one conversion pass over each row. Additionally,
we optimize the premultiply since we know each color component of
the pixel is identical.
This will also enable us to follow up with platform specific
optimizations.
PNG Decode Time Nexus 6P (for a test set of GrayAlpha encoded PNGs)
Regular Unpremul 0.95x
Zero Init Unpremul 0.94x
Regular Premul 0.91x
Zero Init Premul 0.90x
BUG=skia:4767
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1665583002
Review URL: https://codereview.chromium.org/1665583002
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
