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
diff --git a/src/views/SkWindow.cpp b/src/views/SkWindow.cpp
index ebe56b0..82c1a43 100644
--- a/src/views/SkWindow.cpp
+++ b/src/views/SkWindow.cpp
@@ -326,7 +326,13 @@
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;