[RFC] DeepColor Visual Class Extension

[Keith Packard]

Aaron Plattner <aplattner at nvidia.com> writes:

>>> 3. Colorspace/Encoding Window Properties
>>>
>>> Windows with DeepColor visuals must rely on window properties, as opposed to
>>> colormaps, to determine the relationship between pixel values and colors. These
>>> properties must specify constants that correspond to
>>> colorspace/encoding pairs.

Instead of properties, I'd suggest just having the extension
report this data directly. This provides a more direct mechanism which
doesn't end up being exposed to legacy applications.

>>> Servers that support the DeepColor extension MUST, when initialized, create a
>>> child of the root window named "DEEPCOLOR_PROPERTIES".

Just have an extension which can be queried; no magic properties needed.

>> Would there be any benefit to making these a 3-tuple of { colorspace,
>> pixel format, score } ? Thinking there might be hardware where FP16 is
>> enough more painful than 10bpc that performance would be unacceptable. 
>> Though, if that were true, that's almost certainly true regardless of
>> the associated colorspace, so maybe pixel formats just want a separate
>> priority list, or maybe there are so few pixel formats that it's
>> obvious what to do.

Making this too complicated will just have applications getting it
wrong; is there any particular reason to want to support formats which
can't be drawn reasonably efficiently?

>>> If an external application becomes responsible for compositing and supports the
>>> DeepColor extension, it MUST override this property with its own supported
>>> colorspaces/encodings prior to calling XCompositeRedirectSubwindows on the root
>>> window. The server MUST delay sending the PropertyNotify event for the change in
>>> _DEEPCOLOR_COMPOSITOR_COLORSPACES until after the root window hierarchy has been
>>> redirected.

Having this done through an extension would avoid any issues with event
ordering, you'd have the compositor declare format support which would
be automatically reported when the redirection happened. And when the
compositor crashed, the server would clean up naturally. Otherwise, a
crashed compositor would leave the stale property value in place.

> It's not clear to me exactly how nested HDR should work.

Yeah, a good question. We've never dealt with multi-plane support in
Composite as it arrived just as we settled on 32bpp everywhere.

There are a couple of alternatives:

 1) All in the compositor:

    a) Manually traverse the application tree looking for different
       visuals.

    b) Manually redirect windows across visual change boundaries

 2) All in the server:

    a) Redirect to a single pixmap of depth suitable to hold the deepest
       visual.

     b) Composite all window contents to this pixmap.

 3) Multi-redirect

    a) Construct multiple pixmaps at the redirect boundary, one per
       depth/format in the underlying heirarchy

    b) Paint each window into the appropriate pixmap

    c) Compositor then constructs final image from the multiple pixmaps

  4) Bail

    a) Require applications to use a single visual in their application

> It seems to me like you'd want to be able to add HDR support to some
> window (e.g. the Blender 3D modeling windows or GIMP's image window)
> and have its HDRness punch through the window tree without having to
> change the toolkit to draw all the menus and buttons and whatnot in
> HDR too. But maybe that's not a big deal?

If the HDR visual was exposed as a regular core visual with compatible
rendering, then this would be easy -- just have the whole application
share the HDR visual with the HDR-aware portions drawn with HDR APIs and
the non-HDR-aware portions drawn with traditional APIs (see 'Bail' above).

> How this is handled seems like a server implementation detail, but I
> guess adding an extension request doesn't cost much given that we're
> already adding a new extension anyway.

Yup; if the whole formats support is exposed through the extension,
then we can make it work without messing with the semantics of properties.

>> This spec makes no provision for creating >32bpp pixmaps. We could
>> infer that they're possible from this pixel format list, but then doing
>> anything with them will be impossible until a core/Render interaction
>> is defined.

Hrm. We could define an extension request to create HDR pixmaps which
used the HDR format (and depth? bpp?). The HDR extension would provide a
mapping from real format to the core format/depth (perhaps in terms of a
Render pict format?) so that applications would know how to draw to it
using core/render requests. At some point, we could consider extending
Render to handle HDR formats.

I'm not sure this is an immediate requirement; the goal of this
extension seems to be in making direct rendering HDR applications work
correctly, not in adding HDR drawing to the protocol.

> I'm worried that having to deal with the details of getting this
> illusion completely right is going to be a distraction toward the goal
> of getting full-screen HDR games or video to work.

Agreed. I'd say we need to figure out enough to get a direct-rendered
HDR window presented on the screen. With an HDR-aware compositor, in HDR
mode, otherwise in standard X mode (ick). That means:

 1) Exposing HDR visuals through an extension. I think they should be
    normal TrueColor visuals with new attributes visible through the
    extension.

 2) Ignoring the multi-plane aspects and assume that an HDR application
    will have a uniform HDR visual for all windows. Anything else is a
    pile of core X server and Composite work (see above).

 3) Defining core/HDR pixel transform semantics so that existing
    compositors, screen capture and VNC utilities continue to work.

 4) Exposing HDR redirected pixmaps to advanced compositors who can then
    paint from them using direct rendering.

The complexity of disclosing the capabilities of the compositor to
applications seems unnecessary to me; I would assume that an 'HDR-aware'
compositor would be able to deal with all of the formats supported by
the direct rendering APIs on the system. In which case, I'd suggest that
applications shouldn't attempt to match their request to the compositor
in use, and just assume that the compositor is HDR aware. This will
simplify applications and prepare for an environment in which
compositors are HDR aware.

> I guess if push comes to shove, we could ship something that implements
> the rest of the spec with broken or missing SDR conversion support,
> behind an option you have to explicitly enable.

I'd say that SDR conversion is the base requirement; without that, there
are a pile of configurations which will fail. I guess I'm confused why
SDR to HDR conversion is considered 'hard'.

-- 
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.x.org/archives/xorg-devel/attachments/20170914/b7c70787/attachment.sig>