[PATCH] protocol: deprecate wl_surface.damage

[Simon Ser]

On Monday, November 5, 2018 9:44 AM, Pekka Paalanen <ppaalanen at 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.