SampleApp now displays gamma-correct content in "S32" and "F16" modes. The default framebuffer is always (?) sRGB, but querying it to determine that is difficult or impossible. In addition, when running in "L32" mode, we stil want to exhibit the old behavior, where we pretended that it was not sRGB. Thus, set the pixel config of the render target based on the window's color and profile types. That triggers our code to turn on linear->sRGB conversion-on-write in flushRenderTarget.

NOte: Angle does not display correctly, due to limitations in the set of ES2 extensions it exposes. However, it can still be used to generate gamma-correct images (via DM, etc...).

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1752473002

Review URL: https://codereview.chromium.org/1752473002

1 files changed, 7 insertions, 1 deletions

diff --git a/src/views/SkWindow.cpp b/src/views/SkWindow.cpp
index ebe56b0e95..82c1a43c0a 100644
--- a/src/views/SkWindow.cpp
+++ b/src/views/SkWindow.cpp
@@ -326,7 +326,13 @@ GrRenderTarget* SkWindow::renderTarget(const AttachmentInfo& attachmentInfo,
     GrBackendRenderTargetDesc desc;
     desc.fWidth = SkScalarRoundToInt(this->width());
     desc.fHeight = SkScalarRoundToInt(this->height());
-    desc.fConfig = kSkia8888_GrPixelConfig;
+    // TODO: Query the actual framebuffer for sRGB capable. However, to
+    // preserve old (fake-linear) behavior, we don't do this. Instead, rely
+    // on the flag (currently driven via 'C' mode in SampleApp).
+    desc.fConfig = (info().profileType() == kSRGB_SkColorProfileType ||
+                    info().colorType() == kRGBA_F16_SkColorType)
+        ? kSRGBA_8888_GrPixelConfig // This may not be the right byte-order
+        : kSkia8888_GrPixelConfig;
     desc.fOrigin = kBottomLeft_GrSurfaceOrigin;
     desc.fSampleCnt = attachmentInfo.fSampleCount;
     desc.fStencilBits = attachmentInfo.fStencilBits;