On Tue, 2019-01-15 at 11:30 +0200, Pekka Paalanen wrote: > On Tue, 15 Jan 2019 13:47:07 +1100 > Graeme Gill <grae...@argyllcms.com> wrote: > > > If done in the composer, it would need to render the graphic elements to > > the output DPI / convert the source colorspace to the output colorspace. > > But the composer would need the code to do rendering / convert colorspaces > > (as well as being told what the graphic elements / source colorspace is), > > and this is not the role Wayland has - that's the responsibility of the > > client, so instead Wayland makes it possible for the client to know what DPI > > it is rendering to. The analogous facility for CM is for the client to know > > what output colorspace it is rendering for. > > Yes and no. Yes, we do and should let clients know what kind of outputs > their contents will be shown on. However, we will in any case need the > compositor to be able to do the full and correct conversion from what > ever the client has submitted to what is correct for a specific output, > because nothing guarantees that those two would always match.
This isn't necessarily true. The server is free to just draw a black rectangle (or nothing) instead if the image doesn't match the target colorspace. If you want to handle the case of cloned outputs or crossing output borders, let the client attach one image per output colorspace if it wants, and let the server send the client events to indicate when it should start or stop drawing to a particular colorspace. You need that complexity in the client's renderer anyway, why add it to the server's? > One wl_surface on multiple outputs is an obvious case where one buffer > rendered by a client cannot match all the outputs it is shown on. The > other case is transitions between outputs, where we cannot have the > compositor wait for the client to re-draw with new color parameters. Honestly I think of this as an implementation issue? If we take the above multiple-images approach, then if it's my compositor I just omit drawing actors onto any output where there isn't an image for that colorspace, because I am comfortable saying any further latency is the client's renderer's problem. Someone else's compositor might try to bend the existing image to the output colorspace until the client has caught up, believing close-but-wrong color is better than visible absence of color. I could see an argument for either implementation depending on the environment, and I don't really see why the protocol spec should require one or the other. - ajax _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
