[RFC wayland] protocol: Add wl_surface.buffer_damage

[Pekka Paalanen]

On Mon, 16 Nov 2015 10:19:39 +0000
Daniel Stone <daniel at fooishbar.org> wrote:

> 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.

This was my first preference too.

"damage_buffer" is fine by me. Or even "damage_in_buffer".


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20151116/d6ec6d58/attachment.sig>