aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/images
diff options
context:
space:
mode:
authorGravatar brianosman <brianosman@google.com>2016-06-02 05:49:21 -0700
committerGravatar Commit bot <commit-bot@chromium.org>2016-06-02 05:49:21 -0700
commit33f6b3f6ee4de24282f5e7f2dc31a5f538bcf40c (patch)
treea42a432cb1d2460a2de870f4506271c720d5b0e7 /src/images
parent0851d2d04716ad4a7c7a646a5846a81db3d5b925 (diff)
Manually generated sRGB mipmaps, with successively smaller draws.
Dirty GL-generated mipmaps whenever an sRGB texture is used with a new value for TEXTURE_SRGB_DECODE. Add a new test rectangle to the gamma GM that tests that textures are correctly converted to linear before filtering when generating mipmaps. Added a new unit test that alternates how a texture is interpreted (sRGB or not), to verify that we rebuild mipmaps when needed, and that we get the correct results out in both modes. This test originally failed on four of our bots producing incorrect mips in three different ways. I'm not real surprised, but it looks like we can't rely on glGenerateMipmap to do the right thing, in conjunction with TEXTURE_SRGB_DECODE. Instead, actually create mip-chains using a series of draw calls. (My first attempt used glBlitFramebuffer, and that still had bugs on several bots). This approach appears to work correctly on any device that fully supports sRGB. Because the mipmap draws are fairly destructive to state, I had to hoist them out of bindTexture. That means adding a second pass over the texture accesses in the processor, at the very beginning of flush. BUG=skia: GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1840473002 Review-Url: https://codereview.chromium.org/2007973002
Diffstat (limited to 'src/images')
0 files changed, 0 insertions, 0 deletions