Gamma correct rendering with Wayland and Weston

[John Kåre Alsaker]

On Fri, Sep 28, 2012 at 10:51 PM, Bill Spitzak <spitzak at gmail.com> wrote:
> Actual rendering of window contents is not done by Wayland so it should not
> effect this. However wayland and the shells do some compositing, and gamma
> changes how any partially-transparent pixels work. In current shells these
> are:
>
> 1. "shadows", which are typically drawn by the client as
> partially-transparent black and composited over the contents of lower
> windows.
>
> 2. "semi-transparent" objects, such as some of the drag icons. Drawn by the
> clients as pre-multiplied srgb.
>
> 3. The anti-aliased edges of any non-rectangular opaque objects, such as any
> windows that are not rectangular, the cursor, drag icons. Depending on the
> application these may be srgb or linear, though the difference is hard to
> see.
Doing compositing in linear space would change the appearance of
transparent objects, and in the case of shadows, for example, clients
might be interested to know about the compositing space. I don't think
legacy clients doing blending in sRGB will care much (they look all
wrong anyway), but perhaps clients doing blending in linear space will
care when the compositor is blending in sRGB.

>
> Wayland also does scaling and rotations but the difference between linear
> and srgb is much smaller for these. I think the real solution for this is to
> allow clients to know the actual transform of their surfaces to the screen
> and be allowed to draw the transformed image, since this will avoid
> resampling and filtering, as well as letting the clients choose the color
> space.
Part of the point of Wayland is that clients shouldn't know about how
they are placed or transformed, even if they did, the compositor would
still have to compose them and know about the gamma encoding they use.

>
> I suspect that if there are two windows and one is "linear" and another is
> "srgb", that it will be impossible to make the "shadows" of these two
> windows look identical, even if the shadows are drawn in different colors
> and opacity. It may work for black, but not for any color shadows, and it
> certainly will not work for semi-transparent objects.
If two windows have different encodings, they unlikely to be using the
same toolkit and will look completely different anyway.

>
> Therefore I feel that wayland shells should use the same compositing rules
> for all windows, so it is possible for them to all match.
>
> The client is free to use linear compositing into a window but this will not
> change how wayland composites that window with otehrs. When drawing the
> "shadow" it just has to draw whatever will produce the correct srgb values
> in the buffer.
>
> In the future wayland may do linear compositing. But this will change for
> all windows at once. The "appearance library" that should be used to draw
> all the widgets and shadows will be aware of this and alter how it draws
> them.
You seemed to have gotten the impression that I suggested we blend
each surface in either sRGB or linear depending on it's encoding.
That's not what I was suggesting. The compositor won't pick it's
blending gamma space per surface. It's either completely linear or
sRGB. So all clients with the same alpha values (and colors) will look
equal independent of their gamma encoding. We should probably expose
the blending gamma space, so clients have a chance to adjust their
translucent parts, even if most of them will ignore it.

>
>
> John Kåre Alsaker wrote:
>>
>> Currently most applications are blissfully unaware of the concept of
>> gamma which affects pretty much all rendering operations.