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. Cheers, Daniel _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel