On Tue, 15 Jan 2019 13:19:00 +0100 Niels Ole Salscheider <niels_...@salscheider-online.de> wrote:
> Am Dienstag, 15. Januar 2019, 10:30:14 CET schrieb Pekka Paalanen: > > 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. > > > > 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. > > I think the last proposal of a color management protocol that we discussed > does that. It contains the device link profiles and it also allows the client > to query the profile of wl_outputs. With that, an application can display > accurate colors in nearly every situation, even on multiple screens > simultaneously. But still the compositor can do it's best to provide a good > output in some corner cases (e. g. when a new screen is activated and the > application has not rendered a new frame yet). Once the application reacts to > that change the output will be perfect again. Sounds good! Sorry, I have not had a chance to refresh my memory on that proposal, but I have high hopes that it will fit the HDR use case nicely. Thanks, pq
pgpGHijxErVWI.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
