On Monday, November 5, 2018 9:44 AM, Pekka Paalanen <[email protected]> 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. _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
