[RFC wayland] protocol: Add wl_surface.buffer_damage

[Derek Foreman]

On 13/11/15 02:03 AM, Pekka Paalanen wrote:
> On Thu, 12 Nov 2015 13:48:10 -0600
> Derek Foreman <derekf at osg.samsung.com> wrote:
> 
>> On 12/11/15 01:27 PM, Jason Ekstrand wrote:
>>> Thanks for picking this up!  Also, thanks for posting this on the bug,
>>> I would have missed it otherwise!
>>
>> Thanks to Pekka for prodding me to do so. :)
>>
>>> On Thu, Nov 12, 2015 at 11:16 AM, Derek Foreman <derekf at osg.samsung.com> wrote:
>>>> On 09/11/15 09:06 AM, Pekka Paalanen wrote:
>>>>> On Fri,  6 Nov 2015 12:55:19 -0600
>>>>> Derek Foreman <derekf at osg.samsung.com> wrote:
>>>>>

<elided some context>

>>>>>> +    Mixing wl_surface.buffer_damage and wl_surface.damage requests
>>>>>> +    on the same surface will result in undefined behaviour.
>>>>>
>>>>> Why undefined? The compositor will always transform between surface and
>>>>> buffer coordinate systems: surface to buffer for texture updates, and
>>>>> buffer to surface for repaint damage.
>>>>>
>>>>> I suppose you can avoid accumulating two different regions depending on
>>>>> the coordinate space until wl_surface.commit by saying only one
>>>>> coordinate space is guaranteed to work at a time. Is that reason
>>>>> enough, or the only reason?
>>>>
>>>> Just lazy.  I don't want to care about it or have to test it.  Saying
>>>> not to mix them within a commit is just fine too, I think.
>>>>
>>>> Realistically, I can't imagine anyone wanting to do this in the first
>>>> place, so I didn't see much point in spending any time verifying the two
>>>> requests worked well together.
>>>>
>>>> I suppose it'd be possible to slaughter clients trying to mix them -
>>>> would that be preferably to undefined?
>>>
>>> We could say that it's the union of the two but I kind of like "don't
>>> do this" better.
> 
> Don't do this indeed, but should it be a fatal error, or just
> undefined? Or defined as whole-surface damage? :-)
> 
> I have hard time making my mind. If it's not a fatal error, I am sure
> someone will do it even if by accident. When someone does it, I'd
> expect the undefined behaviour to be practically damaging the whole
> surface, so you wouldn't easily notice it.
> 
> So... for the sake of forcing programs to be more correct, make it a
> fatal error? In which case we need a new error code in wl_surface.

Interesting problem just occurred to me...  I don't think just not
mixing damage/buffer_damage within a commit is good enough.

What if a client commits faster than the screen refresh rate?  Then
we're expected to accumulate the damage inside the compositor, right?

So a client could use damage exclusively in one commit, damage_buffer
exclusively in another, and the compositor still has to mix the result...

Is it too heavy handed to allow the first damage/damage_buffer to set
what must be used on the surface for its lifetime?