Sub-surface protocol

[Pekka Paalanen]

On Mon, 17 Dec 2012 15:47:43 +0000
Richard Hughes <hughsient at gmail.com> wrote:

> On 5 December 2012 14:32, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > One of the most important use cases is a video player in a window. It
> > has XRGB or ARGB window decorations, usually the video content in YUV,
> > and possibly an ARGB overlay for subtitles etc. Currently, the client
> > has to color-convert the video, and merge it with the decorations and
> > subtitles, before sending the grand ARGB buffer to the compositor.
> 
> Sorry to be late to the party. A subsurface idea was what Øyvind and I
> were discussing at the OpenICC hackfest when we were talking about
> tagging a surface with a known ICC profile. This would allow a toolkit
> to declare a window area to be AdobeRGB or some home-created camera
> profile from a jpeg that has been tagged with an embedded color
> profile.
> 
> The use case are image viewers like EOG or editors like GIMP. Gimp
> wants to color correct the main preview window converting from source
> ICC profile to monitor ICC profile, but we really don't want to "turn
> off" the sRGB->monitor profile for the selector widgets. By using a
> subsurface we get the behaviour we want without adding tons of code.
> At the moment Oyranos has some kind of xatom protocol to let the
> compositor know an opt-out-region and this isn't ideal or suited at
> all to wayland.
> 
> Anyway, I just wanted to say "rock on" and maybe to keep ICC color
> correction at the back of your mind for the sub-surface. :)

Cool, yeah, I think color management of individual sub-surfaces will
not be a problem, as long as the color management interfaces deal with
wl_surface and wl_buffer objects from the core protocol. In my current
plan, sub-surfaces are wl_surface objects with a particular role, so
color management should interact in obvious ways, and work with minimal
additional changes.


Thanks,
pq