Почему мы сравниваем wayland с композитингом и иксы без?)

В одинаковых условиях - что в случае waylandа по дефолту и правильно работающих иксов (без разрывов), что в случае wayland со включённым тирингом и рвущимися иксами - wayland имеет МЕНЬШИЙ input latency

> Можно же элементарно погуглить "wayland input lag".

Что собственно тебе и будет говориться во всей выдаче гугла, погугли сам)

Композитинг в иксах (пристроенный поверх цельного монолита)  и композитинг в wayland, являющийся частью пайплайна — это концептуально разные вещи.

Вместо многоуровневой буферизации кадров, увеличивающей input lag, wayland просто отдаёт их в момент когда кадр отрисован целиком. «Every frame is perfect». Поэтому и input lag ниже чем в иксах.

А для самых отмороженных киберкотлет, которым безразлично на качество картинки, на уровне отдельных приложений можно и это отключить. И лаг будет ещё меньше.

Окна остаются изолированы, лишь появляется процесс pipewire который и занимается передачей видео, а запрос прав доступа к окну переходит со стороны приложения в xdg desktop portal
У этого и преимущества есть - приложениям не нужно отличать запись всего экрана от записи отдельного окна, в desktop portal можно выбрать оба варианта, и это хорошо работает, в отличии от того как в иксах каждое приложение само реализовывало сложный диалог выбора

Приложение не имеет прямого доступа к чужим окнам, и ему не нужно заниматься костылями чтобы на всех иксовых композиторах захват происходил правильно (Смотри сколько для правильного захвата экрана/окон в иксах пришлось делать в obs)

Это делается стандартными протоколом ext-tray-v1, либо нестандартными jay-tray-v1 и каким-то в kde plasma
Freedesktop для этого DBus спецификацию подготовили https://www.freedesktop.org/wiki/Specifications/StatusNotifierItem/

К сожалению, реализовано пока мало где, однако там где реализовано оно работает правильно, потому что WM лучше знает где нужно рисовать окна, чем приложения

И не говори что не натыкался на то что приложение не в том углу открывает свою штуку, потому что не ожидает что у тебя трей находится не справа внизу (а кто-то справа вверху всегда ожидал)

Тормоза со внеднением к сожалению вызываны ещё и тем, что многие считают трей ненужным, гномовцы в первую очередь, и потому что все старые реализации были так себе сделаны (И это не проблема wayland, на иксах тоже было много протоколов для этого: https://blog.tingping.se/2019/09/07/how-to-design-a-modern-status-icon.html)

Однако последний дизайн (ext-tray-v1) вроде как всем нравится, потому что в нём учтены все ошибки всех старых протоколов

> Ну, или еще задачка. Как сказать ВМу под вейландом, что моему приложению не нужна кнопка распахнуть во весь экран? Во всяком случае через QML мне это неудалось реализовать.

Если оно не resizeable - то не должно быть кнопки разворачивания