Any protocol documentation about premultiplied alpha?

[Carsten Haitzler]

On Tue, 28 Sep 2021 13:16:36 +0000 "Hoosier, Matt" <Matt.Hoosier at garmin.com>
said:

premultiplpied is the base assumption. you don't need shaders to deal with it -
the gl blend func does... the only time you want a shader to deal with
"premultiplied" is if the source buffer is NOT premultiplied - you now have to
do the extra multiply in-shader (or switch blend func). premultiplied is the
sane colorspace for compositing/rendering where things just work out nicely.

> Hi there,
> 
> 
> 
> Is there any definitive word about whether or not clients should be expected
> or allowed to premultiply alpha the alpha channels in the normal EGL and
> linux-dmabuf buffers they send to a compositor?
> 
> 
> I have never seen this practice used with Wayland -- the shaders in the
> gl-renderer certainly don't seem to expect clients to premultiply. But I
> stumbled on a comment or two that maybe gnome-calculator [1] does this and
> that Sway settled on that convention [2].
> 
> 
> 
> I see hardly any mention of premult in the Weston codebase. In fact, the only
> real reference to it occurs at a site dealing with Pixman color formats. In
> this location, it's a prominent warning to the reader that Pixman does use
> premultiplication; this seems to carry the meaning that Pixman's premult
> usage stands apart from the rest of Weston.
> 
> 
> To me, it seems that Wayland's adoption of the DRM_FORMAT_xxx identifiers in
> the wire protocols (e.g., dmabuf) combined with drm_fourcc.h's complete
> stonewalled silence on the subject, seems to be a fairly strong indicating
> that premultiplication should not be used.
> 
> 
> 
> -Matt
> 
> 
> [1] https://github.com/swaywm/wlroots/issues/984#issue-324334642
> 
> 
> [2] https://github.com/swaywm/wlroots/issues/984#issuecomment-390221778
> 
> 
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - raster at rasterman.com