[PATCH] protocol: deprecate wl_surface.damage

[Pekka Paalanen]

On Mon, 5 Nov 2018 13:52:24 -0600
Derek Foreman <derek.foreman.samsung at gmail.com> wrote:

> On 11/5/18 7:43 AM, Simon Ser wrote:
> > On Monday, November 5, 2018 11:07 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:  
> >> 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.  
> > 
> > Fair enough, I'll rephrase with words like "should" and "preferred".
> > 
> > It would be nice to really deprecate this request at some point.  
> 
> Have we ever considered having a way to deprecate requests (beyond
> deprecating entire xml files like the old xdg versions)?
> 
> We could generate compile time warnings and perhaps print a log message.

Compile time warnings don't work with apps that will never be rebuilt
again (proprietary apps).

Log messages are compositor-specific and will get ignored, unless they
actually feed into a system that correctly identifies the application
and automatically submits a bug report at least somewhere.

You could define a deprecation XML attribute that will have the code
generator produce log messages, but where would those messages go?

Therefore I have no hope of ever actually stopping implementing a
request for something as fundamental as e.g. wl_surface.

For all the same reasons, deprecating "entire xml files", or a whole
tree of protocol object types, is risky, because there can be apps that
cannot be updated to not require it. This is one reason why the
wayland-protocols stabilization process takes so long.

> Actually removing protocol might be kind of scary, but we can give
> people some way to know that they might get better performance with some
> changes.

This would be possible given we assume that applications still have
active maintenance.

> Or is this so infrequent an occurrence that it doesn't need to be
> bothered with?

A good plan would be nice, but I have no idea what it might be. Right
now the situation is the same as with library ABI stability rules,
except we do not have the option to keep an ancient library for an
ancient app, since this is about protocol. A middle-man Wayland proxy
daemon could probably convert between deprecated and current stuff.
That's obviously a very heavy solution, not much short from a
full-blown compositor.

In my opinion, ignoring the existence of binary-only applications would
be short-sighted.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20181106/3e989a02/attachment.sig>