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

> Hi,
> 
> On 14 November 2015 at 07:55, Jason Ekstrand <ja...@jlekstrand.net> wrote:
> > On Nov 13, 2015 10:43 AM, "Derek Foreman" <der...@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

Attachment: signature.asc
Description: PGP signature

_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Reply via email to