Is anti-aliasing color processing correct in this image? I have the impression that there is a problem with anti-aliasing in a 2D GUI framework using opengl. To demonstrate the problem I made a program that draws gray ramps. The result is shown below.

The top and bottom gray ramps are identical and considered the reference ramps. It is a copy from &quot;What every coder should know about gamma&quot;. This is what I currently assume that we should see when gray colors are correctly encoded. There seam to be a rounding error in this ramp, so an exact match is not required. The right most rectangle is not perfectly white.
The second gray ramp counting from the top is produced by drawing each rectangle as a stack of black lines not thicker than a pixel on a white background. The thickness of the lines reduces linearly as we go from black to white. The gray color result thus purely from anti-aliasing.
The third gray ramp is simply a sequence of rectangles filled with linearly increasing gray values.
I was expecting that all gray ramps would look identical, but clearly the second gray ramp is not. It seam that a gamma correction has been applied to it while I think it should not.
It generates artifacts which are strongly visible in font rendering as shown below.

The text a has been produced with the library in question, and the text b has been produced with another font rendering library.
Another test I did to put in evidence the artifacts resulting from the anti-aliasing color processing is to draw slightly slanted lines.

The lines above are produced by the library in question and the lines below by another library. The thickness of the lines below look more uniform. The lines above look wrong and distorted.
The author of the 2D graphic library claims that his color processing with anti-aliasing and filled rectangle is correct.
Who is right ? What argument could I use to resolve this disagreement ?
The more I work on this subject, the more I get confused. For instance, by using a color picker I see that the color in the center of the ramp of the reference image is close to 0x7F. Is the color picker giving the color in linear space or the sRGB color value ? The screen color picker is Gpick (Gnome Linux).
I know that we should work in linear color space when performing operations on images. What is unclear is what am I looking at ? The color values I gave to rectangles where linear, not sRGB, or not gamma corrected. The color ramp I see seam linear. The values given by the color picker seam to match the linear value I gave.
The anti-aliasing rendering is correct.
The reference gray ramp (top and bottom) is linear in sRGB color, not in brightness.
The second gray ramp made with anti-aliasing is linear in brightness. The rectangle color (black in color sRGB space) is mapped to linear space (remains black), then anti-aliasing is computed, and the resulting image is converted back to sRGB. It is thus not linear in sRGB value anymore.
The RGB values given by a screen color picker are in  sRGB color space, and the color values of a screen capture are in the sRGB color space.
SVG and nearly all browser graphic library (skia and cairo) are doing it wrong. They compute anti-aliasing over sRGB instead of linear color. They thus don't convert back from linear to sRGB. The same mistreatment  is also visible on Windows, MacOs and iOS.
The filled rectangle gray ramp doesn't have this problem because the conversion from sRGB to linear and its inverse cancel out.