diff options
author | Mike Klein <mtklein@chromium.org> | 2017-05-03 15:04:23 -0400 |
---|---|---|
committer | Skia Commit-Bot <skia-commit-bot@chromium.org> | 2017-05-03 21:10:03 +0000 |
commit | a4f3e14d896708376aa50b2a8804796e6e1ee644 (patch) | |
tree | 6aac11f739d8ebc19e705e53b0548b3389d597eb /.gitignore | |
parent | 0f353327968530506dd3dd15fca79ef59fe013f1 (diff) |
treat SkPMColor as sRGB in SkPM4f::FromPMColor()
We made the wrong call in SkPM4f::FromPMColor(). SkPM4f::FromPMColor()
is only used by the color correct drawing pipeline, not legacy. That
means it makes a lot more sense to treat SkPMColors as premul sRGB than
premul linear.
You can see the effect very clearly in any code path using the fallback
SkShader::Context::shadeSpan4f(). We shade legacy 8888, then
"linearize" to float by calling SkPM4f::FromPMColor(). At head we're
not really linearizing, which means everything ends up too bright in the
end. Things get double sRGB-encoded, etc.
It is expected that this CL will make many color correct images look
darker and a lot more like legacy mode. It may be jarring... we've
gotten used to seeing this bug and thinking brighter == fixed.
The only GM that changes in actual legacy 8888 is gamut, which
explicitly creates non-legacy 8888 images... the diff there is expected.
Change-Id: I77ac6cfe8f7ffb15e90f4aad798dbe8f9d3aafbd
Reviewed-on: https://skia-review.googlesource.com/15227
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Herb Derby <herb@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Diffstat (limited to '.gitignore')
0 files changed, 0 insertions, 0 deletions