Bowing my head in shame, going back to gamma interpolated gradients
Frankengradients (linearly interpolated RGB, gamma interpolated alpha) look
fantastic but unfortunately create sligh compatibility issues. For instance,
a gradient from 0xffea1030 to 0x00ea1030 (opaque to alpha, with a single
color) blended on top of 0xff101010 would not look the same as a single
opaque gradient from 0xffea1030 to 0xff101010. The difference is hardly
noticeable on simple gradients but it could cause confusion amongst app
developers. Their life is hard enough as it is, let's be good to them.
My crusade against the gamma world is not over and one day I shall
be the victor. I am patience.
Bug: 35485208
Test: UiRendering.ShaderTests, UiRendering.GradientTests, manual testing
Change-Id: I8204e60cdf0a6b12dfe22638d30ca9622687000e
diff --git a/libs/hwui/FloatColor.h b/libs/hwui/FloatColor.h
index d8afa35..a738ba4 100644
--- a/libs/hwui/FloatColor.h
+++ b/libs/hwui/FloatColor.h
@@ -38,13 +38,14 @@
}
// "color" is a gamma-encoded sRGB color
- // After calling this method, the color is stored as a linear color. The color
- // is not pre-multiplied.
- void setUnPreMultipliedSRGB(uint32_t color) {
+ // After calling this method, the color is stored as a un-premultiplied linear color
+ // if linear blending is enabled. Otherwise, the color is stored as a un-premultiplied
+ // gamma-encoded sRGB color
+ void setUnPreMultiplied(uint32_t color) {
a = ((color >> 24) & 0xff) / 255.0f;
- r = EOCF_sRGB(((color >> 16) & 0xff) / 255.0f);
- g = EOCF_sRGB(((color >> 8) & 0xff) / 255.0f);
- b = EOCF_sRGB(((color ) & 0xff) / 255.0f);
+ r = EOCF(((color >> 16) & 0xff) / 255.0f);
+ g = EOCF(((color >> 8) & 0xff) / 255.0f);
+ b = EOCF(((color ) & 0xff) / 255.0f);
}
bool isNotBlack() {