[RFC] DeepColor Visual Class Extension

[Keith Packard]

Alex Goins <agoins at nvidia.com> writes:

> Thanks, Adam.
>
> Here's an updated version of the spec:

This is looking very good. I don't have any architectural concerns at
this point, just some editorial comments.

> Rendering to DeepColor windows using the core protocol, however, is loosely
> defined.

It seems to be actually fairly well defined to me. If core pixel values
could be 'round-tripped' through the deep storage, then core rendering
would be exact. That seems pretty simple with the UINT* formats when
used with a non-linear colorspace -- just use an identity mapping.

For a linear color space using FP format, I wonder if you could define a
function that would result in reliably transferring 256 levels in and
out of each primary?

The principle reason I ask is that if pixel values can be reliably
stored in deep visuals, then the existing testing infrastructure can be
used to validate the implementation.

>     scRGB_Linear describes an scRGB color space with linear OETF. scRGB uses the
>     same primaries and white point as sRGB, and the linear encoding is best used
>     with an FP16 pixel format.

I think you should define "OETF" in the spec; most people reading this
will not know where to start looking for a definition.

> COLORSPACE { type:  COLORSPACETYPE
>              gamma: FIXED }

Could you just use a FLOAT here? glx uses IEEE floats all over its
protocol, so it wouldn't be a new type on the wire. I'm a bit sorry to
not have used floats for Render; that was done when many smaller
embedded systems still lacked floating point hardware and we were
concerned about the performance implications of floats in the rendering
path. For this extension, there's no performance impact here, and using
a real float would be better. Heck, if you like, use a 64-bit IEEE float.

>     DPCSelectInput
>
>         window: WINDOW
>         enable: SETofDPCSELECTMASK
>
>         Errors: Window, Value

Either this request should always deliver an event or never deliver an
event. Having it 'sometimes' deliver events seems messy. I'd suggest
just having it always deliver one of each of the events selected; it's
easy to implement and, as you say, avoids race conditions when the
developer combines this with the query in the wrong order. That's
actually a nice cleanup compared with similar functionality in existing
functions.

>     A composite manager must use a color space/encoding supported by the
>     display(s) when compositing into the target window.

What error is returned if this isn't done? And wouldn't a regular
application, running in non-composited mode, also have the same
requirement? After all, a compositing manager is just a regular client
drawing to a regular window.

>     DPCOverrideCompositorCapabilities

>     The set of outputs represented in 'overrides' must be complete, and the set
>     of color spaces/encodings associated with each of them must be identical or
>     the capabilities will be cleared instead of updated to the new set, still
>     generating a DPCCompositorChangeNotify event.

I think this means the compositing manager is required to emit one of
these requests for each output? If so, why not simply place all of those
in a single request so that we can verify that the compositing manager
did the right thing?

What happens when another output is added to the screen?

>     For applications, this must be an option supported by the compositor, and
>     must be updated in response to DPCCompositorChangeNotify events. Rendering
>     using options not supported by the compositor will result in undefined
>     graphical behavior.

I'd really rather this be 'should' and not 'must'. Given that we have
reasonable well-defined behaviour for conversion to core pixel values,
any colorspace not directly supported by the compositing manager can be
supported using core/render operations, leaving clients still functional
even with a mismatch between their colorspace and the compositing
manager colorspace.

In its current form, this places a higher burden on applications than
compositing managers here -- they *must* support whatever colorspace the
compositing manager offers, while the compositing manager is free to
support only those it likes.

>     Composite managers are expected to use this request to indicate to the
>     server which color space is being used for rendering into the target window.
>     In this case, the option must be supported by the display. Rendering using
>     options not supported by the display will result in undefined graphical
>     behavior.

I'm not happy with 'undefined' behaviour here. We've got three moving
pieces here (display, compositor, app) and things only work right when
they all follow the rules, and those rules are subject to arbitrary
change as you start/stop compositing managers and connect/disconnect
displays.

I think a simple requirement is that the application be allowed to
choose any colorspace it likes and that, at worst, the image presented
on the screen will have been restricted to the associated core visual
precision. That's well defined by the spec and will mean that
incompatibilities between applications, compositing manager and display
will only result in lower-fidelity images, not 'undefined' results.

> 9. Issues
>
> This spec does not address the suggestion that window color space/encoding
> should reflect that of the next frame. It is difficult to determine what the
> "next frame" is without the Present extension, and a concrete solution has yet
> to be found.
>
>     * Perhaps this functionality could be the domain of an interaction between
>       the Present extension and DeepColor-aware clients, where clients hand off
>       the responsibility for finalizing the color space/encoding of a window to
>       the Present extension, which would atomically update it with the
>       presentation of the next frame before generating
>       DPCWindowChangeNotify.

Yup. Should work fine. This should be done using a separate request so
that applications can still set the colorspace without using
Present. Essentially, the application would do

        SetNextPresentColorspace
        PresentPixmap

and the colorspace seen by the compositor when it receives the
associated damage will be the new one. Hrm. It will receive that in an
event, presumably directly before the Damage event. The compositor would
be wise to look for a damage event when it receives the new colorspace
information, or perhaps it could infer that only future contents as
indicated by Damage events should be interpreted in the new colorspace? 

-- 
-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/20171015/7d764c44/attachment.sig>