How is this intended to work in Wayland?
Are clients supposed to tell the compositor what color space their
buffer is, and the compositor then converts to the output's color space
as part of the compositing step? Problems with this:
* We need a reliable way for clients to tell compositor what color
space they are rendering, ideally without huge amounts of code such as
the same color space converter library in the client.
* Fast conversion of an 8-bit buffer between color spaces reduces the
effective number of bits of color to 7 or even 6, and can introduce ugly
artifacts. Adding enough noise (what most shaders call dithering) can
hide this but obviously adds noise. Computing the output color space at
higher accuracy and then doing proper error diffusion dithering is
better, but slow on many GPUs. Requiring the buffers to be higher than
8-bit precision can fix this but people may question Wayland's
commitment to allowing efficient clients.
* Is "same as the output" a supported color space?
Or are clients supposed to get the color space needed and convert to it
when rendering their buffers? This seems more Wayland-like but has problems:
* problem if the surface is on more than one output
* multiple copies of the color-correction library and loaded color
space descriptions in each client
* need for message from compositor to client to change the color
space, and compositor must wait for commit from all clients before
updating the screen.
* Clients may not have access to the color correction hardware that
the compositor has.
Richard Hughes wrote:
I've attached three patches for comments and review. I'm a GLib
programmer at heart, so please be kind if I've made huge obvious
architectural mistakes :)
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
