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
signature.asc
Description: PGP signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel