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>
diff --git a/src/gpu/ops/GrAtlasTextOp.cpp b/src/gpu/ops/GrAtlasTextOp.cpp
index 29a5938..d956755 100644
--- a/src/gpu/ops/GrAtlasTextOp.cpp
+++ b/src/gpu/ops/GrAtlasTextOp.cpp
@@ -297,8 +297,9 @@
}
SkASSERT(proxies[0]);
- auto pipe =
- target->makePipeline(fSRGBFlags, std::move(fProcessors), target->detachAppliedClip());
+ static const uint32_t kPipelineFlags = 0;
+ auto pipe = target->makePipeline(kPipelineFlags, std::move(fProcessors),
+ target->detachAppliedClip());
FlushInfo flushInfo;
flushInfo.fPipeline = pipe.fPipeline;