[RFC wayland] protocol: Add wl_surface.buffer_damage

[Daniel Stone]

Hi,

On 14 November 2015 at 07:55, Jason Ekstrand <jason at jlekstrand.net> wrote:
> On Nov 13, 2015 10:43 AM, "Derek Foreman" <derekf at osg.samsung.com> wrote:
>> 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?
>
> I think it's better to just let the client damage however it wants and
> highly recommend they pick one and stick with it.  It's perfectly
> well-defined to damage in both and trying to come up with a precise
> condition for a protocol error is, as you pointed out, rather difficult. The
> only sane condition I can think of is "don't use both in the same commit"
> but, as you pointed out, that doesn't actually help the compositor.
> Compositors that don't want to deal with it can just stomp to full damage as
> soon as things get complicated.

I completely agree. Trying to make the spec too rigidly defined will
ultimately end up in compositors not quite getting it right and people
getting surprised at the variance. If a particular compositor
pessimises too hard, then that compositor will be rightly noted for
its non-performance and eventually fixed. The worst case would be
changing a transform at the same time as submitting damage in both
buffer and surface co-ords, at which point you'll probably want to
stomp to full damage. Which is fine, as I can't really imagine why you
_wouldn't_ be sending full damage when sending a buffer with a totally
different transformation to previous.

Cheers,
Daniel