Am 20.12.2016 um 03:38 schrieb Graeme Gill: > Niels Ole Salscheider wrote: >> What MIGHT be possible is that an application provides the complete surface >> in >> all color spaces of all outputs so that the compositor can use the parts it >> needs. > > Yes, that's an interesting thought.
It appears to be expensive to me. [But there might be tricks like area events to signal repaint demand.] > Another thought that avoids > the application having to know the exact surface to output mapping > would be for the application to provide a device link for > each output (I'm currently thinking through the implications > of such an approach.) Device Link ICC profile solve the desire to completely describe a conversion inside the display encoding (3*precision_of_choice). A device link could be used to * provide a relatively simple means for injecting values to the GPU shaders. ( That needs to carefully define a compatibility subset. Device links can have lots of features like all other ICC profile classes, which are hard to reimplement. Close to what we see in compositors are 3D LUT support. Extending that by curves makes a lot of sense to support the desired gamma 1.0 blending spaces: e.g. matrix/shaper curves[ICC v2], parametric curves[ICC v4] + 3D LUTs[mtf2 ICC v2] || [mAB ICC v4]. ) * compositors can read plain values from the device link profile without any conversion by a ICC CMM * applications gain a lot of flexibility, like support for effects etc. * a agent could take over the device link creation for all applications, which do not know about howto on the downside: * clients need to see output changes to supply a matching ICC device link for the new/changed device * device links work not for n > number of display channels (cmyk is impossible that way). The n-channels (n >= 4) clients need still information about outputs + window regions. > Both ideas have similar issues - > you really want the per output pixels or device links to > be provided by the application on demand - i.e. when a surface > first overlaps an output, so that it doesn't have to pre-compute > pixels or device links for all possible outputs, even if they > never get used. This has interactivity implications. I think Pressing the monitor simulates a new space or adding a new hot monitor triggers a similar update demand. Maybe the device link is kind of a extension for later implementation. Kai-Uwe _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
