Sub-surface protocol

[John Kåre Alsaker]

On Tue, Dec 18, 2012 at 2:59 PM, John Kåre Alsaker
<john.kare.alsaker at gmail.com> wrote:
> On Tue, Dec 18, 2012 at 6:40 AM, Bill Spitzak <spitzak at gmail.com> wrote:
>>
>> 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.
>>
>> 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.
> I don't see any problem with doing that unless you want different bit-depths.
>
>>
>>

You could also construct the window decorations out of 4 subsurfaces
and get alpha working on the center subsurface, but I doubt that's
particularly useful.