Updated every switch that yelled at me, and added support to dm and fm,
and then founds some more switches that shouldn't have defaults...
The tricky spots outside those were mips and dither,
since they aren't simply exhaustive switches.
_Now_ no diffs between RGB/BGR 1010102 and 101010x.
No GPU support.
Bug: skia:9893
Change-Id: I73ab3fd22bdef0519296dfe4cb84031e23ca0be3
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/270114
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Use std::min and std::max everywhere.
SkTPin still exists. We can't use std::clamp yet, and even when
we can, it has undefined behavior with NaN. SkTPin is written
to ensure that we return a value in the [lo, hi] range.
Change-Id: I506852a36e024ae405358d5078a872e2c77fa71e
Docs-Preview: https://skia.org/?cl=269357
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/269357
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Change-Id: I7adc1e01f4f9cec56e53e620ba4d04eae61f0b9e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/254899
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
There are still some present (being used by Chromium or Android),
but I think all of these are internal-only.
Change-Id: I80177a65e0ea737e88ab7bb1ef36d03edebd4fa4
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/255138
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
I'd rather catch uninitialized input here than
somewhere deep down in zlib or libpng.
Bug: chromium:1013368
Cq-Include-Trybots: skia.primary:Test-Debian9-Clang-GCE-CPU-AVX2-x86_64-Debug-All-MSAN
Change-Id: I37f5a66a8fc12c7e0ce6d3100de94021bb5343ef
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/248551
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Everything except for SkImageInfo.h is mechanical
Change-Id: I2d775c79467fb15f6022e80d21b4a9151272fe2a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/242896
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
This CL adds:
kAlpha_F16_SkColorType
kRG_F16_SkColorType
kRGBA_16161616_SkColorType,
which should be it for a while.
Bug: skia:9121
Change-Id: I81b9d46a202a76e9b7d7ca86495d72dbdae32576
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/241357
Commit-Queue: Robert Phillips <robertphillips@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Reviewed-by: Mike Reed <reed@google.com>
This also switches GrColorType::kR_16 to kAlpha_16 to more closely match raster.
Bug: skia:9121
Change-Id: I03c6e6c52c90aa4223478c5ea6c8b2ed8558f677
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/239930
Commit-Queue: Robert Phillips <robertphillips@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Bug: chromium:951893
This will help determine which piece of code left memory uninitialized.
Add a test that exercises all the different ways we might pass memory
to jpeg_write_scanlines.
Change-Id: I6392a414795da9b0471e8cd6b373a7fff8f0a1b1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/225098
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
This reverts commit 940c3f136d.
Reason for revert: <INSERT REASONING HERE>
Original change's description:
> add runtime registration for encoders
>
> If we want to make these external dependencies mix-and-match in Google3,
> we'll need to group together the encoders and decoders, everything that
> dependends on each external library.
>
> I was tempted to try to remove these generic encoder entrypoints and
> replace them with calls to the direct equivalents, but I'm not sure
> that's necessary. I think we can just register encoders like decoders.
>
> Change-Id: I41d2d1bb3ceb1daafa62c95d345eb6a70249be75
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/213880
> Commit-Queue: Mike Klein <mtklein@google.com>
> Reviewed-by: Brian Osman <brianosman@google.com>
TBR=mtklein@google.com,scroggo@google.com,brianosman@google.com
Change-Id: I3ee9353ca6b3c6c11feba0503b672d8986a347be
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/214107
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
This reverts commit 32c32b9a6c.
Reason for revert: <INSERT REASONING HERE>
Original change's description:
> unguard SkFooEncoder.cpp
>
> We used to define SkFooEncoder::Encode() either
> here or as failing stubs in SkImageEncoder.cpp.
>
> Now that we're not defining them in SkImageEncoder.cpp,
> we can lift these guards here.
>
> Change-Id: Id916811225450e4c3a84f1e7f38ae510be1d6268
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/214004
> Reviewed-by: Leon Scroggins <scroggo@google.com>
> Commit-Queue: Mike Klein <mtklein@google.com>
TBR=mtklein@google.com,scroggo@google.com
Change-Id: I089a21d2fd4928969d956e47981a36efa71d9378
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/214101
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
We used to define SkFooEncoder::Encode() either
here or as failing stubs in SkImageEncoder.cpp.
Now that we're not defining them in SkImageEncoder.cpp,
we can lift these guards here.
Change-Id: Id916811225450e4c3a84f1e7f38ae510be1d6268
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/214004
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
If we want to make these external dependencies mix-and-match in Google3,
we'll need to group together the encoders and decoders, everything that
dependends on each external library.
I was tempted to try to remove these generic encoder entrypoints and
replace them with calls to the direct equivalents, but I'm not sure
that's necessary. I think we can just register encoders like decoders.
Change-Id: I41d2d1bb3ceb1daafa62c95d345eb6a70249be75
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/213880
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Add a shim to redirect until clients are updated
Change-Id: Ib43614e5620b1a24ca18187c1646a8ed1a9ee7a4
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/211003
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Current strategy: everything from the top
Things to look at first are the manual changes:
- added tools/rewrite_includes.py
- removed -Idirectives from BUILD.gn
- various compile.sh simplifications
- tweak tools/embed_resources.py
- update gn/find_headers.py to write paths from the top
- update gn/gn_to_bp.py SkUserConfig.h layout
so that #include "include/config/SkUserConfig.h" always
gets the header we want.
No-Presubmit: true
Change-Id: I73a4b181654e0e38d229bc456c0d0854bae3363e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/209706
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Hal Canary <halcanary@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
skcms is part of Skia's public API now. This attempts to recognize that,
and pave the way for moving the header to another location more easily
in a follow up CL, or - at a minimum - for clients that redistribute
Skia as a library + includes to relocate the skcms.h header as part of
that.
Change-Id: I15da63b0d4ab8916a71fb7e6ab3656db87252707
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/209640
Reviewed-by: Mike Klein <mtklein@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
For now this is distinct from kRGBA_F16_SkColorType but treated the
same. Next steps are to see if we can keep it clamped to [0,1].
Switched a few switches away from default to exhaustive.
Took away any explicit SW clamps for now except the one we definitely
want in append_gamut_clamp_if_normalized().
Skip F16Norm in the DDL test because we can't yet distinguish it from
F16.
Change-Id: I021a864fe078e4fa4e2b399982e6c38350e10d74
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/196371
Commit-Queue: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
This reverts commit 22170b3178.
It was reverted due to the test breaking Google3. This includes a
workaround.
Original change's description:
> Treat kWEBP encode with quality=100 as lossless
>
> In SkEncodeImage and friends, treat quality of 100 as a lossless encode
> when using kWEBP. This seems a good fit for the intent - which is
> presumably to save the highest quality image. This also matches
> Chromium's blink::ImageEncoder::ComputeWebpOptions, which treats a
> quality of 1 (on a float scale from 0 to 1) as a lossless encode.
>
> FWIW, Chromium has had this behavior since
> https://codereview.chromium.org/1937433002, in response to
> crbug.com/523098. The goal is to "maintain sharpness to
> match the JPEG encoder behavior (use WEBP lossless encoding)".
>
> Add a test to verify the new behavior. This requires making tests
> depend on libwebp to use WebPGetFeatures, since the Skia API does not
> provide a way to determine whether an encoded webp file was encoded
> lossless-ly or lossily.
>
> Bug: skia:8586
> Change-Id: Ie9e09c2f7414ab701d696c4ad9edf405868a716f
> Reviewed-on: https://skia-review.googlesource.com/c/175823
> Commit-Queue: Leon Scroggins <scroggo@google.com>
> Reviewed-by: Derek Sollenberger <djsollen@google.com>
> Reviewed-by: Mike Reed <reed@google.com>
TBR=reed@google.com, based on prior approval
Bug: skia:8586
Change-Id: I09c73f71996422f797fd9456fef5dfad9af36839
Reviewed-on: https://skia-review.googlesource.com/c/194194
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
Auto-Submit: Leon Scroggins <scroggo@google.com>
Most interfaces had migrated to skcms_TransferFunction. Having both was
awkward in several places, so this (almost) finishes the migration. Some
clients are calling SkICC::WriteToICC, so that's left intact. After this
CL, those clients can switch to using SkWriteICCProfile directly, and
WriteToICC can be deleted.
Bug: skia:
Change-Id: I46ebaeb1f5b20bf0c620e8a620e73ee323a1de31
Reviewed-on: https://skia-review.googlesource.com/c/186541
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Previously:
- Gamut could be a 4x4 matrix (overspecified), or an enum.
- Transfer function could be a struct with 7 floats, or one of two
different enums.
- We had 5 of the 6 possible factories covering those [3 x 2] options.
Recently we added a single new factory that takes the skcms 7-float
struct, and the skcms 3x3 matrix. This is the exact, minimal set of
information needed to specify an SkColorSpace.
Major clients have been moved to that factory, so the other five are
being removed. The enums are also being removed, as they are no longer
part of the API. All transfer functions and gamuts covered by the old
enums are available as constexpr values (of the skcms types) in the
header (SkNamedTransferFn and SkNamedGamut).
Bug: skia:
Change-Id: I1fbbacec6997b966dd92000ab67513e7f1a9d023
Reviewed-on: https://skia-review.googlesource.com/c/184067
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This reverts commit e7f165be2e.
Reason for revert: doesn't compile in google3
Original change's description:
> Treat kWEBP encode with quality=100 as lossless
>
> In SkEncodeImage and friends, treat quality of 100 as a lossless encode
> when using kWEBP. This seems a good fit for the intent - which is
> presumably to save the highest quality image. This also matches
> Chromium's blink::ImageEncoder::ComputeWebpOptions, which treats a
> quality of 1 (on a float scale from 0 to 1) as a lossless encode.
>
> FWIW, Chromium has had this behavior since
> https://codereview.chromium.org/1937433002, in response to
> crbug.com/523098. The goal is to "maintain sharpness to
> match the JPEG encoder behavior (use WEBP lossless encoding)".
>
> Add a test to verify the new behavior. This requires making tests
> depend on libwebp to use WebPGetFeatures, since the Skia API does not
> provide a way to determine whether an encoded webp file was encoded
> lossless-ly or lossily.
>
> Bug: skia:8586
> Change-Id: Ie9e09c2f7414ab701d696c4ad9edf405868a716f
> Reviewed-on: https://skia-review.googlesource.com/c/175823
> Commit-Queue: Leon Scroggins <scroggo@google.com>
> Reviewed-by: Derek Sollenberger <djsollen@google.com>
> Reviewed-by: Mike Reed <reed@google.com>
TBR=djsollen@google.com,scroggo@google.com,reed@google.com
Change-Id: I91680f65a2a5e6f0a13b84e97c9541ebe0606b33
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:8586
Reviewed-on: https://skia-review.googlesource.com/c/176584
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Reed <reed@google.com>
In SkEncodeImage and friends, treat quality of 100 as a lossless encode
when using kWEBP. This seems a good fit for the intent - which is
presumably to save the highest quality image. This also matches
Chromium's blink::ImageEncoder::ComputeWebpOptions, which treats a
quality of 1 (on a float scale from 0 to 1) as a lossless encode.
FWIW, Chromium has had this behavior since
https://codereview.chromium.org/1937433002, in response to
crbug.com/523098. The goal is to "maintain sharpness to
match the JPEG encoder behavior (use WEBP lossless encoding)".
Add a test to verify the new behavior. This requires making tests
depend on libwebp to use WebPGetFeatures, since the Skia API does not
provide a way to determine whether an encoded webp file was encoded
lossless-ly or lossily.
Bug: skia:8586
Change-Id: Ie9e09c2f7414ab701d696c4ad9edf405868a716f
Reviewed-on: https://skia-review.googlesource.com/c/175823
Commit-Queue: Leon Scroggins <scroggo@google.com>
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Reviewed-by: Mike Reed <reed@google.com>
I kept reading and re-reading the existing logic and couldn't figure it
out until I looked at the AlphaOption enum. I think this direction
reads a bit more clearly.
(This is why we have those ->premul methods. Oddly, we fail for 4444.)
Change-Id: I74ea2e380d5ab9526ea1e6412929346ad9c0ead6
Reviewed-on: https://skia-review.googlesource.com/c/167921
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I8c0e47933538034a2ea6f77f86b4d2694014e6b3
Reviewed-on: https://skia-review.googlesource.com/c/167686
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Change-Id: Iacbddf1575115852eaa79b3f2e41c3bbbf3124c8
Reviewed-on: https://skia-review.googlesource.com/c/167684
Commit-Queue: Mike Klein <mtklein@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
- remove a couple transform_scanline_procs
- remove all use of SK_RESTRICT
- remove the color table
- reformat arguments etc.
Change-Id: I545dc6d74fffc7d95e3d53fb26ee748b94f93b65
Reviewed-on: https://skia-review.googlesource.com/c/167683
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
The distinction between SkJumper and SkRasterPipeline used
to be important, but it's no longer. This CL moves everything
under src/jumper to the appropriate SkRasterPipeline file.
Change-Id: I1181fffafccb3dc4c4eb5f33b442c719ee370462
Reviewed-on: https://skia-review.googlesource.com/c/164627
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
It's been driving me nuts that I can't just write `SkMatrix44 m;`,
and I often don't care whether it's initialized or not. The default
identity constructor would be nice to use, but it's deprecated.
By tagging this constructor deprecated, we're only hurting ourselves;
our big clients disable warnings about deprecated routines and use it
freely.
A quick tally in Skia shows we mostly use the uninitialized constructor,
but sometimes the identity constructor, and there is a spread of all
three in Chromium. So I've left the two explicit calls available.
I switched a bunch of calls in Skia to use the less verbose constructor
where it was clear that it didn't matter if the matrix was initialized.
Literally zero of the kUninitialized constructor calls looked important
for performance, so the only place I've kept is its lone unit test.
A few places read clearer with an explicit "identity" to read.
Change-Id: I0573cb6201f5a36f3b43070fb111f7d9af92736f
Reviewed-on: https://skia-review.googlesource.com/c/159480
Reviewed-by: Brian Osman <brianosman@google.com>
Change encode-srgb-* to exercise this code. The encoders
handle this just fine, so just remove those checks. The
decoders still rely on having a color space, so detect
and fix this inside SkCodec. Eventually I'd like to get
rid of the swizzler, use skcms for all format conversion,
etc... but that's a really big change, and this will let
us land other changes without breaking layout tests.
Bug: skia:8382
Change-Id: I8d85bf44ee3a287ad295515a745ded2ff5051417
Reviewed-on: https://skia-review.googlesource.com/156627
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Change-Id: Ieac05047826b1fb80950d65573d38494a1a5c5e7
Reviewed-on: https://skia-review.googlesource.com/148383
Commit-Queue: Hal Canary <halcanary@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
Auto-Submit: Hal Canary <halcanary@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
- Encoders and decoders always assume kIgnore.
- They are less opinionated about F16 and color space,
we just trust the color space that's passed in, and
put that directly in the image (no sRGB encoding).
- SkBitmap and SkPixmap read/write pixels functions were
defaulting to kResepct, those are now always kIgnore.
- Many other bits of plumbing are simplified, and I
added a default of kIgnore to SkImage::makeColorSpace,
so we can phase out that argument entirely.
- Still need to add defaults to other public APIs that
take SkTransferFunctionBehavior.
- This makes gold think that we've dramatically changed
the contents of all F16 images, but that's because
it doesn't understand the (now linear) color space
that's embedded. Once we triage them all once, they
will work fine (and they'll look perfect in the browser).
Bug: skia:
Change-Id: I62fa090f96cae1b67d181ce14bd91f34ff2ed747
Reviewed-on: https://skia-review.googlesource.com/140570
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Draws basically the same as f16.
The existing load_f32, load_f32_dst, and store_f32 stages all had the
same bug that we'd never noticed because dy was always 0 until now.
Change-Id: Ibbd393fa1acc5df414be4cdef0f5a9d11dcccdb3
Reviewed-on: https://skia-review.googlesource.com/137585
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Reed <reed@google.com>
What makes an info valid (or invalid)? Nothing to do with
color space.
Bug: skia:
Change-Id: I6795efa9aa74ab0d65935c5ddccc1058f8e0b112
Reviewed-on: https://skia-review.googlesource.com/131780
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Code:
- Add a non-linear blending bit and makeNonlinearBlending()
to SkColorSpace
- remove enough F16=linear checks to make it possible to
create surfaces and encode pngs with nonlinear F16
Testing:
- add "esrgb" software config to DM, run it
- add "srgbnl" software config, run it
- deemphasize importance of "srgb" config on bots
- update unit tests to reflect relaxed F16 constraints
- add a new unit test file with _really_ basic tests,
and a new unit test that's not working yet
Bug: skia:7942
Change-Id: I8ac042bdf9f3d791765393b68fd9256375184d83
Reviewed-on: https://skia-review.googlesource.com/127325
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Most of SkICC{.h,.cpp} is unused and gone.
I've renamed the part that's left to SkWriteICCProfile() and tweaked its
API just a little, leaving SkICC:WriteToICC() a wrapper around it.
Most of the tests in ICCTest.cpp are moot and deleted, but a few looked
somewhat valuable so I've kept them with a little modification.
Change-Id: Ia1bb4c772af679885e17dac53d213c315ad0828c
Reviewed-on: https://skia-review.googlesource.com/127022
Auto-Submit: Mike Klein <mtklein@chromium.org>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Same sort of deal as before, now with all three new formats.
While I was at it, I made sure RGBA 8888 and BGRA 8888 both work too.
We don't want the 101010's in lowp, but 888x should be fine.
After looking at the DM images on monitors at work, I decided to
re-enable dither even on 10-bit images.
Looking at the GMs in 888x or 101010x is interesting... I think we must
not be clearing the memory allocated for layers? Seems like we want to
allocate layers as 8888?
Change-Id: I3a85b4f00877792a6425a7e7eb31eacb04ae9218
Reviewed-on: https://skia-review.googlesource.com/101640
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
The type SkColorSpace_Base doesn't need to exist. Its one type() query
can be answered instead by toXYZD50().
Now all that's left in the file is SkGammas, so rename it to SkGammas.h.
Change-Id: Id60ddbfb342accfd5674ae89b37a24a6583ef7b8
Reviewed-on: https://skia-review.googlesource.com/99702
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
It's now no different than append(from_srgb).
Bug: skia:7419
Change-Id: I97c59b6987f033ec2f1859db40ca3056b87b370a
Reviewed-on: https://skia-review.googlesource.com/86741
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Some pieces still remain, but the next step looks less mechanical,
so I wanted to land this piece independently.
Bug: skia:
Change-Id: Ie63afcfa08af2f6e4996911fa2225c43441dbfb2
Reviewed-on: https://skia-review.googlesource.com/84120
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Brian Osman <brianosman@google.com>
Pushes and pops nested jmp_bufs in a stack for proper handling of
nested setjmp calls. Ensures longjmp is never called to a stack frame
that has exited.
Bug: skia:
Change-Id: I18d62504f6e5e3eb53026c3b48617b92ea74b905
Reviewed-on: https://skia-review.googlesource.com/79241
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
This reverts commit 5411a60e0d.
Reason for revert: ASAN and Coverage failing: https://chromium-swarm.appspot.com/task?id=394978f3b7d44610
Flutter_Android failing.
Original change's description:
> Add an Option for orientation on JPEG encodes
>
> Move Origin to its own header so that SkPixmap and SkJpegEncoder need
> not depend on SkCodec.
>
> Add libexif, which is already used by Android, and use it to write the
> orientation. Write a makefile based on the Android.bp in Android, minus
> warnings. (libexif has an LGPL license.)
>
> Add a test that verifies all the orientations work.
>
> Optionally enable writing the orientation (and therefore including
> libexif). Chromium does not currently need it, and Android does not
> expose an API that would allow using it. Disable on Windows, where we
> still have build errors to fix.
>
> Bug: skia:7138
> Change-Id: Iaeff44c36aebe0e639666979dc00e1b7594bbeb1
> Reviewed-on: https://skia-review.googlesource.com/60721
> Commit-Queue: Leon Scroggins <scroggo@google.com>
> Reviewed-by: Mike Klein <mtklein@chromium.org>
> Reviewed-by: Mike Reed <reed@google.com>
TBR=mtklein@chromium.org,mtklein@google.com,scroggo@google.com,reed@google.com
Change-Id: I05b7ae8d1c5bbd1de1642d9ef024943500256273
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:7138
Reviewed-on: https://skia-review.googlesource.com/61620
Reviewed-by: Ben Wagner <benjaminwagner@google.com>
Commit-Queue: Ben Wagner <benjaminwagner@google.com>
Move Origin to its own header so that SkPixmap and SkJpegEncoder need
not depend on SkCodec.
Add libexif, which is already used by Android, and use it to write the
orientation. Write a makefile based on the Android.bp in Android, minus
warnings. (libexif has an LGPL license.)
Add a test that verifies all the orientations work.
Optionally enable writing the orientation (and therefore including
libexif). Chromium does not currently need it, and Android does not
expose an API that would allow using it. Disable on Windows, where we
still have build errors to fix.
Bug: skia:7138
Change-Id: Iaeff44c36aebe0e639666979dc00e1b7594bbeb1
Reviewed-on: https://skia-review.googlesource.com/60721
Commit-Queue: Leon Scroggins <scroggo@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Reviewed-by: Mike Reed <reed@google.com>
This CL enables us to set the default visibility of the symbols
on Android to hidden. It is the intent that all of he SK_APIs
that have been added to /src directies should be removed as soon
as we can remove their callers within Android.
Bug: b/31971097
Change-Id: Ic787f94df0fb0c2b8d941aa7095a12b317c4b5de
Reviewed-on: https://skia-review.googlesource.com/49501
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Derek Sollenberger <djsollen@google.com>
created new file src/core/SkColorData.h for
internal consumption. Note that many of the
functions there are unused as well.
Bug: skia: 6898
R: reed@google.com
Change-Id: I25bfd5a9c21f53558c4ca65a77eb5d322d897c6d
Reviewed-on: https://skia-review.googlesource.com/46848
Commit-Queue: Cary Clark <caryclark@google.com>
Reviewed-by: Mike Reed <reed@google.com>
