Re: [csswg-drafts] [css-color-hdr] Requesting Absolute HDR Mode and listed differences from Adaptive HDR Mode (#10998)

Our approach on Wayland is probably different than in your mind. If an application like a game is rendering for the display at hand, it says so to the window system by explaining the colorimetric properties of the imagery it produces. When the window system sees that the produced content matches the display at hand, it has no need to apply any tone mapping or other.

Doing this kind of automatic opportunistic optimization and fast paths is at the core of making Wayland compositors performant. We use similar decisions frame-by-frame for bypassing the GPU(*) composition completely by taking an application framebuffer and putting it directly on the display whenever that is possible. Applications are mostly oblivious to this, and there are no explicit "go-fast modes" that apps would need to choose.

This also means that Wayland does not need to provide any "direct to display" pixel paths for applications. It's always automatic based on the applications correctly describing the image content they provide. Since applications cannot provide multiple versions of the same window content optimized for different outputs, we can still show the same window on multiple different outputs with as good quality as automatic gamut and tone mapping allows. These other outputs may be things like secondary monitors, screenshots, screen recordings, and remote desktop viewers. Having a pixel path where application content is guaranteed to be forwarded to a monitor as-is with no information like mastering limits would preclude all those use cases.

> Maybe "Performance HDR" should require (native/borderless/bordered) fullscreen, to overcome the multi-window concerns?

If I again talk about Wayland, there is no difference between native, borderless and bordered fullscreen.  In the end, the compositor has the application framebuffer, and if all conditions have been met, that framebuffer will skip composition and go straight to the display controller for scanout. This means we can use hardware overlays and underlays automatically even for windowed content and not just in fullscreen cases.

If we have multiple simultaneous windows each with different color characteristics, then all windows whose characteristics do not match the characteristics of an output will get automatic gamut and tone mapping. The quality of that mapping is chosen by the system based on user preferences, e.g. high quality vs. power efficiency based on AC vs. battery.

Personally I am very fond of this "apps describe what they have, and the window system displays it in the best possible way anywhere the user likes" approach. It's all automatic and applications do not need to guess whether they can or should try some go-fast modes. Of course, for adaptable applications Wayland provides the preferred color characteristics which the application can choose to use and tag its window with.

----

(*) For me, GPU and display controller are separate entities. GPU is the big power-hungry 3D core, while the display controller generates the video signals from in-memory framebuffers in a very power efficient manner. Both can be used for composition, but compositing on the display controller is much more limited. Hence we have Wayland compositors use the display controller opportunistically.

-- 
GitHub Notification of comment by ppaalanen
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10998#issuecomment-2441169239 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 28 October 2024 10:21:56 UTC