[RFC] DeepColor Visual Class Extension

[Adam Jackson]

On Thu, 2017-10-26 at 19:50 -0700, Alex Goins wrote:

>     DPCGetWindowDisplayCapabilities
> 
>         window: WINDOW
>         =>
>         output: OUTPUT
>         colorspace_list: LISTofCOLORSPACEPRIORITY
> 
>         Errors: Window
> 
>     DPCGetWindowDisplayCapabilities functions identically to
>     DPCGetDisplayCapabilities, but rather than explicitly specifying an output,
>     the user must specify a window. The request then retrieves a list of color
>     spaces/encodings and their associated scores from the output upon which the
>     window is centered.

Does this need to do something special for root windows? Is "whatever
the root is centered on" good enough? How do you break ties for a 2x2
grid of identically-sized monitors? ("Pick something" is fine, anyone
doing that with four non-identical monitors is kind of being a jerk.)

Does it make sense to send an event when this would change, ie, when
the window's center crosses outputs? The app is going to want it, it
seems silly to require a round trip to get it. If so, does the ordering
matter with respect to the associated ConfigureNotify?

>     DPCOverrideCompositorCapabilities
> 
>         output: OUTPUT
>         colorspace_list: LISTofCOLORSPACEPRIORITY
> 
>         Errors: Output, Match
> 
>     Used by a composite manager to override the set of possible color
>     spaces/encodings and associated scores for composition for a given output.
> 
>     If used before requesting RedirectSubwindows on the root window, changes
>     will not take effect until a subsequent redirection of the root window
>     hierarchy by the requester has completed. Color spaces/encodings associated
>     with each output must be identical, but scores may vary. If a composite
>     manager fails to fulfill these requirements before requesting
>     RedirectSubwindows on the root window, the server will instead empty the set
>     of capabilities on each output, generating a DPCCompositorChangeNotify event
>     for each.
> 
>     If used after the root window hierarchy has been redirected by the
>     requester, changes take effect immediately. The set of color
>     spaces/encodings specified must match those of other outputs on the screen,
>     or a Match error results. Scores, however, may differ from other outputs.
> 
>     DPCCompositorChangeNotify events will be generated on the appropriate root
>     window when the compositor capabilities are changed by this request. If
>     applicable, the changes do not take effect until after the subsequent
>     redirection of the root window hierarchy has completed, thereby delaying the
>     generation of the event.

I think this request should take a list of { output, colorspace_list }
tuples so the request can complete atomically. Once you've redirected
the root window there's no reasonable way for the server to defer
sending the CompositorChangeNotify events, so updating the scores for
every output could generate one event per output, clients would need to
guess how many more colorspace changes are coming before re-rendering,
or else do redundant, possibly racy work.

>     DPCCompositorChangeNotify
> 
>         requester: WINDOW   window requesting notification
>         output: OUTPUT      output affected by change
>         colorspace_list: LISTofCOLORSPACEPRIORITY  updated compositor capabilities

Likewise I think this event should return a list.

- ajax