[PATCH] protocol: deprecate wl_surface.damage
contact at emersion.fr
Mon Nov 5 08:58:46 UTC 2018
On Monday, November 5, 2018 9:44 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> 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
More information about the wayland-devel