On Mon, 05 Nov 2018 08:58:46 +0000 Simon Ser <cont...@emersion.fr> wrote:
> On Monday, November 5, 2018 9:44 AM, Pekka Paalanen <ppaala...@gmail.com> > wrote: > > Hi, > > > > what good does this do, when no compositor can ever stop implementing it? > > > > I'm ok with adding a note that clients might have easier time using > > damage_buffer, but I don't see anything that would allow compositors to > > do otherwise. Err, well, that note is what you are replacing here. > > > > Whatever the compositor, it will always have to translate from one > > space to the other space, regardless of which request a client is > > using. You need the buffer space damage to be able to update textures > > (wl_shm path), and you need the surface space damage to repaint the > > screen (for framebuffer damage). > > As you said, the compositor needs to do two things with damage: (1) update > textures (buffer coords) and (2) damage outputs (surface coords). > > If we only get buffer damage from clients, then (1) is easy and (2) requires a > single region transformation. > > If we get surface damage and/or buffer damage from clients, then both (1) and > (2) require region transformations. > > As said in the commit message, surface damage interactions with wp_viewporter > are hard to understand. > > In the end, I still think having one code path for damage submission is a net > win. I don't see why clients would need to use surface damage instead of > buffer > damage. How about writing what Derek said: that the old damage request may be unoptimal rather than deprecated. I don't like "deprecated" because to me it implies that this request will be removed (i.e. can be left unimplemented) some time in the future. Xwayland is still using exclusively wl_surface.damage, for instance. Thanks, pq
pgpeCA6SO7oKa.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel