Re: wl_surface::attach(NULL) release previous buffer?

2023-09-17 Thread John Cox
On Fri, 15 Sep 2023 21:53:34 +, you wrote:

>> Ideally the release event would have been a wl_callback just like 
>> wl_surface.frame is.
>
>I sent [1] to fix this.
>
>[1]: https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/137

That would have been nice but it doesn't look like it made it?

Thanks

JC


Re: Questions about object ID lifetimes

2023-09-17 Thread jleivent
Has altering the wire format to contain all the info needed for
unambiguous decoding of each message entirely within libwayland without
needing to know the object ID -> type mapping been considered?

It would make the messages longer, but this seems like it wouldn't be
very bad for performance because wire message transfer is roughly
aligned with user interaction speeds.

Also, for any compositor/client pair, as long as they both use the same
version of libwayland, the necessary wire format change would not
result in compatibility issues.  It would for static linked cases,
or similar mismatching cases (flatpak, appimage, snap, etc. unless
the host version is mapped in instead of the packaged one somehow).
There also seem to be unused bits in the existing wire format so that
one could detect an a compositor/client incompatibility at least on one
end.

I'm not suggesting that unambiguous decoding of all messages is a
sufficient fix, but it is a necessary one.  There are still speculative
computation issues that it wouldn't resolve alone.