Alex Goins <ago...@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
signature.asc
Description: PGP signature
_______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel