Sub-surface protocol

[Kai-Uwe Behrmann]

Am 18.12.2012 06:40, schrieb Bill Spitzak:
> On Dec 17, 2012, at 5:01 PM, John Kåre Alsaker wrote:
>>>
>>> Then a client such as gimp could draw all it's display into a single buffer.
>>> To get the different color correction of the center display, it would
>>> declare a subsurface containing this and set it's color correction
>>> differently using the wayland api. This would only allocate one buffer,
>>> which would save memory, but more importantly it should make internal code
>>> in gimp easier as you could work around a toolkit that assumes only one
>>> output buffer.
>> My approach to color correct rendering in Wayland is to let the
>> compositor handle it and have the clients simply specify which color
>> space they are using. Only the compositor can render clients correctly
>> when they are displayed on multiple monitors (unless we introduce a
>> way to set a buffer per-output).
>
> Yes this is what I am assuming.
>
> What I am asking is if it makes sense for a client to draw two different color spaces into the same buffer. The larger area is color space A, and a rectangular subarea is color space B. It then tells wayland to make the main window color space A, and then makes a subwindow with the clipped subarea and tells wayland that it is color space B.

That is how the X Color Management spec implementations communicate 
between clients and servers. Take a window handle and tag it with a 
region, which in turn points to a ICC profile. I think Martin had a 
similar idea to place regions on own textures for KWin some time ago.

> The reason is to save buffer space, and also to work around toolkits and drawing api's where it is a lot more practical to draw everything into the same buffer.

For this reason Xcm adopted the per region tagging approach. Qt and Gtk 
people tould us, they do not like to expose subwindows.