For destinations, Premul vs. Unpremul is actually meaningful
for these color types - it determines whether or not we divide
through by alpha after blending. Opaqueness ought to just be
a performance hint, and only for sources.
Bug: skia:
Change-Id: I801a64316ec9c92642982cd2096f8bec9a7855f3
Reviewed-on: https://skia-review.googlesource.com/c/161423
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This reverts commit 9835dd51b3.
Reason for revert: Chrome unit tests failing?
Original change's description:
> Fix image info checking for always-opaque color types
>
> The old code overlooked 101010x and 888x. The GPU code for
> readPixels tried to enfore this, but incorrectly, and the
> writePixels code missed it entirely.
>
> Bug: skia:
> Change-Id: Ib69473703f2ae7604d4b21ec6728b7d764becd9a
> Reviewed-on: https://skia-review.googlesource.com/c/161148
> Commit-Queue: Brian Osman <brianosman@google.com>
> Commit-Queue: Brian Salomon <bsalomon@google.com>
> Reviewed-by: Brian Salomon <bsalomon@google.com>
> Reviewed-by: Mike Klein <mtklein@google.com>
> Auto-Submit: Brian Osman <brianosman@google.com>
TBR=mtklein@google.com,bsalomon@google.com,brianosman@google.com
Change-Id: I360375f2bf21576db914f5e177ac56e398ca7023
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:
Reviewed-on: https://skia-review.googlesource.com/c/161380
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
The old code overlooked 101010x and 888x. The GPU code for
readPixels tried to enfore this, but incorrectly, and the
writePixels code missed it entirely.
Bug: skia:
Change-Id: Ib69473703f2ae7604d4b21ec6728b7d764becd9a
Reviewed-on: https://skia-review.googlesource.com/c/161148
Commit-Queue: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Auto-Submit: Brian Osman <brianosman@google.com>
This reverts commit 3b347232bc.
Reason for revert: tree done gone red.
Original change's description:
> SkMath takes some functions from from SkTypes
>
> Moved to include/core/SkMath.h: Sk{Is|}Align{2|4|8|Ptr}, SkLeftShift,
> SkAbs{32|}, SkM{ax|in}32 SkTM{in|ax}, SkTClamp, SkFastMin32, SkTPin.
>
> Change-Id: Ibcc07be0fc3677731048e7cc86006e7aa493cb92
> Reviewed-on: https://skia-review.googlesource.com/133381
> Auto-Submit: Hal Canary <halcanary@google.com>
> Reviewed-by: Ben Wagner <bungeman@google.com>
> Commit-Queue: Hal Canary <halcanary@google.com>
TBR=mtklein@google.com,halcanary@google.com,bungeman@google.com,reed@google.com
Change-Id: I44073cf397e2a3a6a941a90f0aa63c6396d4c742
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/152587
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
There's really no reason to prevent any of these conversions;
they all have somewhat reasonable behavior:
- converting between grey in different color spaces
should probably work just fine
- we'll convert color to gray using a fixed set of
luminance coefficients, but that's better than failing
- we'll invent {r,g,b} = {0,0,0} if we convert alpha
to something with color
- converting to opaque formats without thinking about
premul/unpremul is probably fine, better than just
not working at all
- a missing src color space can always be assumed to be sRGB
Updates to ReadPixelsTest:
- skip more supported test cases in test_conversion(),
each with a TODO
- conversions from non-opaque to opaque should now work
- conversion from A8 to non-A8 should sometimes now
work on GPUs, and the test needed a little bit of
a tweak to not expect A8 to carry around color somehow.
Updates to SRGBReadWritePixelsTest:
- writing untagged pixels shouldn't fail anymore;
instead, it should behave like it was tagged sRGB
Change-Id: I19e78f3a6c89ef74fbcbc985d3fbd77fa984b1c2
Reviewed-on: https://skia-review.googlesource.com/147815
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Osman <brianosman@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>
PS5: Removes SkDestinationSurfaceColorMode, tracking of mipmap
mode on GrTexture, sRGB decode state per-texture. Because we
were often choosing sRGB configs for RGB color types, legacy
rendering would then be incorrect (too dark). So...
PS7: Stops ever using sRGB pixel configs when translating
image info or color type. Also removes a bunch of GrCaps bits
and a GrContextOption that are no longer relevant.
PS9: Adjusts surface creation unit test expectations, and
changes the raster rules accordingly.
At this point, sRGB configs are (obviously) going to be broken.
Locally, I ran 8888, gl, and the gbr- versions of both. Across
all GMs x configs, there are 13 diffs. 12 are GMs that create
surfaces with a color-space attached (and thus, the offscreen
is no longer getting sRGB pixel config). The only remainder
constructs an SkPictureImageGenerator, (with an attached color
space) and renders it to the gbr-gl canvas, which triggers a
a tagged surface inside the generator.
Bug: skia:
Change-Id: Ie5edfa157dd799f3121e8173fc4f97f6c8ed6789
Reviewed-on: https://skia-review.googlesource.com/131282
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Salomon <bsalomon@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>
