For grids, maybe supporting tiling an image would help... it probably could be used in other scenarios as well?

... does color.NRGBA{79,79,79,1} (or something darker than 255) solve your issues?

When blending that value with colors that are brighter than 79, it would end up making them darker and not lighter.

Ah, I know how to illustrate the issue better. Roughly speaking the issue is in using linear u8 for alpha component together with linear blending. First take a look at the https://blog.johnnovak.net/2016/09/21/what-every-coder-should-know-about-gamma/#light-emission-vs-perceptual-brightness.

Moving from the left-side of the gradient if you take a "1 unit" step to the right. The value on "linear gradient" is much brighter than the "sRGB". The solutions are effectively:

1. make a smaller step (by using uint16, float32 or srgb encoding for alpha)
2. use sRGB "gradient" in the first place

color.RGBA(1, 1, 1, 1) isn't a white color with transparency, it's gray with transparency (assuming it's 255 * (linear-non-premul * alpha)^1/2.2 variant).

x := color.RGBA{1,1,1,1}
fmt.Println(f32color.RGBAToNRGBA(r))
// Output: {79 79 79 1}

As a general statement, color.NRGBA is more or as precise as color.RGBA since it doesn't multiply the colors with alpha, which can only "make numbers smaller" (i.e. smaller precision). Alpha itself isn't gamma adjusted, hence it wouldn't encode it into rest of the color components.

However, you can represent colors that are "brighter than 255 and transparent" with "color.RGBA", since you write things like: color.RGBA{255, 255, 255, 1}.

I still quite don't see where the original 13 or the 12.92 in Elias' reply comes from.

The actual linear <-> sRGB conversion isn't a simple exponentiation. See the formulas in https://en.wikipedia.org/wiki/SRGB#Specification_of_the_transformation. The exponentiation is easier to show in formulas.

Also, I don't quite see how "palettes" can be used in a generalized way, because I am applying highlights on stuff like pictures, icons and text etc., so the highlight needs be some kind of blending operation. It gets very complicated for me if every icon needs to know if the icon is being highlighted.

I'm not quite understanding which part of the material design you are implementing. So hard to recommend something specific.

Is standardizing all painting to linear float32 color too expensive (e.g. for mobiles)?

There's a performance overhead, but there's also the memory usage for the buffers. For example, iPhone it's 11.85MB vs 47.6MB for a single screen-sized buffer.

Yes, it should've been "sRGB u8 premul to linear". Typo from copy-paste. And, yes, looks like I made a mistake in the formulas and calculations, however I made two mistakes, so it cancelled out :D.

Here's trying to redo the calculations:

// The definitions:
linear-premul = linear-non-premul * alpha
srgb = (linear-non-premul * alpha)^1/2.2 * 255
==>
linear-non-premul = (srgb / 255)^2.2 / alpha
linear-premul =  (srgb / 255)^2.2 / alpha * alpha = (srgb / 255)^2.2

linear-non-premul = 1.0, alpha=1/255
srgb = (1.0 * 1/255)^1/2.2 * 255
linear-premul = (((1.0 * 1/255)^1/2.2 * 255) / 255)^2.2 = 1/255

Would color.RGBA make any difference in this case?

I don't think it would make a difference when you use color.RGBA as Gio colorspace input. The first conversions would be:

Source  sRGB RGBA        u8  : R:(255*1/255)^1/2.2, A:1
                             : R:1, A:1

// Converting from sRGB u8 non-premul to linear ((srgb/0xff)/alpha)^2.2 * alpha
Source  linear premul    f32 : ((1/255) / (1/255))^2.2 * 1/255, A:1/255
                               1/255, A:1/255

Since the linear premultiplied color is the same the blending will happen in a similar fashion.

Using color.NRGBA64 would allow to specify higher precision.

Do any of you know what other GUI libraries/browsers do about loss of precision problems?

1. Do color blending using sRGB instead of linear (browsers, flutter, most UI-s).
2. Use higher precision (usually in photo editing tools you can choose RGB/8, RGB/16, RGB/32).
3. Use floating values (it's not uncommon to pass vec4 for colors in shaders).
4. Allow switching between sRGB and Linear modes (svg https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/color-interpolation)

So, I walked through the calculations:

// calculations using sRGB gamma approximation
// instead of the actual formula

Source  sRGB NRGBA       u8  : R:255, A:1

// Converting from sRGB u8 non-premul to linear (srgb/0xff)^2.2 * alpha
Source  linear premul    f32 : (255/255)^2.2 * 1/255, A:1/255
                               1/255, A:1/255

// Blending with 1, 1 - srcAlpha
Blended linear premul    f32 : (255/255)^2.2 * 1/255, A:1.0
                               1/255, A:1

// Converting from linear premul to sRGB post-premultiplied,  (linear premul / alpha)^1/2.2 * alpha
Blended srgb post premul f32 : (1/255 / A)^1/2.2 * A, A:1.0
                               (1/255)^1/2.2, A:1.0
                               0.08

// Converting from linear premul to sRGB pre-premultiplied,  (linear premul)^1/2.2
Blended srgb pre  premul f32 : (1/255)^1/2.2, A:1.0
                               0.08, A:1.0

// Converting it to uint8, srgb * 255
Blended srgb * premul   u8 : 255 * 0.08 = 20.4

From pure calculation point of view and color blending view, what Gio does to colors -- seem to be correct. I think the fundamental difference comes from sRGB vs linear blending.

If we switch to non-linear blending, then it would end up with issues, such as: https://blog.johnnovak.net/2016/09/21/what-every-coder-should-know-about-gamma/

However, there's still the issue how to nicely blend colors to get different effects.

With my experiments, using alpha overlays you can easily end up with muted colors (saturation drops), which ideally it shouldn't. You could still do "small alpha" overlays with additive blending, but that would have similar problems.

For themes, I think the solution is to either:

1. predefine the exact colors you want to use (rather than overlays)
2. derive the color from the palette (such as https://git.sr.ht/~eliasnaur/gio/tree/main/item/internal/f32color/rgba.go#L164)

In the case of dark theme you would interpolate towards the accent color or towards white, depending on the usecase. Such approach would give you nicer colors.

But, I do agree that overlays with lower lightness or different color formats could be useful in some other cases. One option would be to pass in a more precise color paint.Color32Op or add some extra "alpha" for all the drawing, e.g. paint.AlphaOp.

When using the webflow it would be nice to set the default "To" address in "Review your patchset".

When working on a project it's quite likely that you are most of the time sending the patchset to upstream. It would be nice to avoid having to find the appropriate mailing list when sending a patchset.

Any reason not to switch depth buffer to 24 bits for now?

64k seems reasonable, 16M less so.