Two (related) changes here:
1) Our older iOS devices failed our sRGB tests, due to precision issues
with alpha. At this point, we only test on iPadMini 4, and that appears
not to have any problems.
2) iOS devices still don't have the sRGB texture decode extension. But,
some clients have no interest in mixing legacy/color-correct rendering,
and would like to use sRGB on these devices. This GrContextOptions flag
enables sRGB support in those cases.
Adjust the test code to produce sRGB capable contexts on these devices,
but only for configs that have a color space. (See comment).
BUG=skia:4148
Committed: https://skia.googlesource.com/skia/+/9db12d2341f3f8722c8b90b11dd4cce138a8a64e
Committed: https://skia.googlesource.com/skia/+/1aeb78c5d978b35b256525b711edd942bce01444
Review-Url: https://codereview.chromium.org/2539993002
diff --git a/tools/flags/SkCommonFlagsConfig.cpp b/tools/flags/SkCommonFlagsConfig.cpp
index abd8bdb..5763e4a 100644
--- a/tools/flags/SkCommonFlagsConfig.cpp
+++ b/tools/flags/SkCommonFlagsConfig.cpp
@@ -185,8 +185,19 @@
if (useInstanced) {
fContextOptions |= ContextOptions::kUseInstanced;
}
+ // Subtle logic: If the config has a color space attached, we're going to be rendering to sRGB,
+ // so we need that capability. In addition, to get the widest test coverage, we DO NOT require
+ // that we can disable sRGB decode. (That's for rendering sRGB sources to legacy surfaces).
+ //
+ // If the config doesn't have a color space attached, we're going to be rendering in legacy
+ // mode. In that case, we can't allow a context to be created that has sRGB support without
+ // the ability to disable sRGB decode. Otherwise, all of our sRGB source resources will be
+ // treated as sRGB textures, but we will be unable to prevent the decode, causing them to be
+ // too dark.
if (fColorSpace) {
fContextOptions |= ContextOptions::kRequireSRGBSupport;
+ } else {
+ fContextOptions |= ContextOptions::kRequireSRGBDecodeDisableSupport;
}
}
static bool parse_option_int(const SkString& value, int* outInt) {