On Nov 13, 2015 10:43 AM, "Derek Foreman" <<a href="mailto:derekf@osg.samsung.com">derekf@osg.samsung.com</a>> wrote: > > On 13/11/15 02:03 AM, Pekka Paalanen wrote: > > On Thu, 12 Nov 2015 13:48:10 -0600 > > Derek Foreman <<a href="mailto:derekf@osg.samsung.com">derekf@osg.samsung.com</a>> wrote: > > > >> On 12/11/15 01:27 PM, Jason Ekstrand wrote: > >>> Thanks for picking this up! Also, thanks for posting this on the bug, > >>> I would have missed it otherwise! > >> > >> Thanks to Pekka for prodding me to do so. :) > >> > >>> On Thu, Nov 12, 2015 at 11:16 AM, Derek Foreman <<a href="mailto:derekf@osg.samsung.com">derekf@osg.samsung.com</a>> wrote: > >>>> On 09/11/15 09:06 AM, Pekka Paalanen wrote: > >>>>> On Fri, 6 Nov 2015 12:55:19 -0600 > >>>>> Derek Foreman <<a href="mailto:derekf@osg.samsung.com">derekf@osg.samsung.com</a>> wrote: > >>>>> > > <elided some context> > > >>>>>> + Mixing wl_surface.buffer_damage and wl_surface.damage requests > >>>>>> + on the same surface will result in undefined behaviour. > >>>>> > >>>>> Why undefined? The compositor will always transform between surface and > >>>>> buffer coordinate systems: surface to buffer for texture updates, and > >>>>> buffer to surface for repaint damage. > >>>>> > >>>>> I suppose you can avoid accumulating two different regions depending on > >>>>> the coordinate space until wl_surface.commit by saying only one > >>>>> coordinate space is guaranteed to work at a time. Is that reason > >>>>> enough, or the only reason? > >>>> > >>>> Just lazy. I don't want to care about it or have to test it. Saying > >>>> not to mix them within a commit is just fine too, I think. > >>>> > >>>> Realistically, I can't imagine anyone wanting to do this in the first > >>>> place, so I didn't see much point in spending any time verifying the two > >>>> requests worked well together. > >>>> > >>>> I suppose it'd be possible to slaughter clients trying to mix them - > >>>> would that be preferably to undefined? > >>> > >>> We could say that it's the union of the two but I kind of like "don't > >>> do this" better. > > > > Don't do this indeed, but should it be a fatal error, or just > > undefined? Or defined as whole-surface damage? :-) > > > > I have hard time making my mind. If it's not a fatal error, I am sure > > someone will do it even if by accident. When someone does it, I'd > > expect the undefined behaviour to be practically damaging the whole > > surface, so you wouldn't easily notice it. > > > > So... for the sake of forcing programs to be more correct, make it a > > fatal error? In which case we need a new error code in wl_surface. > > 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. --Jason