[PATCH] protocol: deprecate wl_surface.damage
ppaalanen at gmail.com
Mon Nov 5 10:07:36 UTC 2018
On Mon, 05 Nov 2018 08:58:46 +0000
Simon Ser <contact at emersion.fr> wrote:
> 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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the wayland-devel