aboutsummaryrefslogtreecommitdiffhomepage
path: root/.gitignore
diff options
context:
space:
mode:
authorGravatar Mike Klein <mtklein@chromium.org>2017-05-03 15:04:23 -0400
committerGravatar Skia Commit-Bot <skia-commit-bot@chromium.org>2017-05-03 21:10:03 +0000
commita4f3e14d896708376aa50b2a8804796e6e1ee644 (patch)
tree6aac11f739d8ebc19e705e53b0548b3389d597eb /.gitignore
parent0f353327968530506dd3dd15fca79ef59fe013f1 (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