Remove sRGB config checks based on color space

All of the restrictions/assumptions that led to this code are gone,
so we can always use appropriate color space.

For the YUV provider, if/when we re-introduce 8888 sRGB, the color
space will have a linear transfer function, so the color space
xform will automatically do what was happening here. That removes
the last usage of framebuffer sRGB control, so we can remove all
kinds of GrPaint and GrPipeline plumbing for that feature.

Change-Id: I24af1d498dbc75210f92f8c61b10aa31eec022f6
Reviewed-on: https://skia-review.googlesource.com/138986
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Brian Osman <brianosman@google.com>

1 files changed, 1 insertions, 5 deletions

diff --git a/tests/ReadWriteAlphaTest.cpp b/tests/ReadWriteAlphaTest.cpp
index d7f4d54ae1..8f72d9b7db 100644
--- a/tests/ReadWriteAlphaTest.cpp
+++ b/tests/ReadWriteAlphaTest.cpp
@@ -191,12 +191,8 @@ DEF_GPUTEST_FOR_RENDERING_CONTEXTS(ReadWriteAlpha, reporter, ctxInfo) {
                 continue;
             }
 
-            sk_sp<SkColorSpace> colorSpace;
-            if (GrPixelConfigIsSRGB(proxy->config())) {
-                colorSpace = SkColorSpace::MakeSRGB();
-            }
             sk_sp<GrSurfaceContext> sContext = context->contextPriv().makeWrappedSurfaceContext(
-                    std::move(proxy), std::move(colorSpace));
+                    std::move(proxy));
 
             for (auto rowBytes : kRowBytes) {
                 size_t nonZeroRowBytes = rowBytes ? rowBytes : X_SIZE;