On 13/11/15 02:03 AM, Pekka Paalanen wrote: > On Thu, 12 Nov 2015 13:48:10 -0600 > Derek Foreman <der...@osg.samsung.com> 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 <der...@osg.samsung.com> >>> wrote: >>>> On 09/11/15 09:06 AM, Pekka Paalanen wrote: >>>>> On Fri, 6 Nov 2015 12:55:19 -0600 >>>>> Derek Foreman <der...@osg.samsung.com> 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? _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel