HDR support in Wayland/Weston

[Pekka Paalanen]

On Tue, 15 Jan 2019 14:14:53 -0500
Adam Jackson <ajax at redhat.com> wrote:

> On Tue, 2019-01-15 at 11:30 +0200, Pekka Paalanen wrote:
> > On Tue, 15 Jan 2019 13:47:07 +1100
> > Graeme Gill <graeme2 at 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.

Hi Adam,

in my opinion it is not acceptable in a Wayland compositor.

Wayland protocol does not say anything about the final visual, so
showing a corrupted window (black, invisible, whatever) is not a
protocol violation per se, but I still think it would be a buggy
compositor if I can observe it.

At least Weston should do better. OTOH, a specialised compositor running
in a fixed environment and very specific use cases might be able to
manage with showing black, because no intended use case would make the
automatic conversion necessary. The protocol shouldn't care, both
implementations should be possible.

If no-one ever triggers a bug, does the bug need fixing?

> 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?

We could do that, but then it would not allow to blend different
windows correctly together. It would only work for completely opaque
windows.

The increase in memory usage would also be significant. The decrease in
overall system performance might be too, though that is not obvious.

> > 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?

Yes, it very much is 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.

That is correct.

The protocol spec will not require one way or another. The protocol
spec only needs to enable both ways.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20190117/54271536/attachment.sig>