> Вроде после прихода pixman нормально стало.

Не ощутил как-то. Почему-то программы, которые явно не вкостылили две дюжины костылей - порядком тормозят по сей день. А на каком месте апликушники, пишущие кроссплатформенный софт вертели идею сильно прыгать под причуды одной конкретной графической подсистемы со всеми ее архаизмами и бестолковостями, задействуя опциональные расширения и прочая - легко догадаться. Поэтому работает оно в целом погано на мой вкус. Мной иксы классифицируются как "проблемный системный компонент, который желательно заменить".

> Скорее не хотят ломать совместимость и тянут кучу legacy.

И это все прекрасно, но времена VGA адаптеров закончились а требования к графике у юзерей стали совсем другие. Вон даже Khronos это просек. И да, их новый vulkan таки будет не совместим с OpenGL. Зато он будет таким каким его хотят видеть те кто им пользоваться будет. Т.е. производители GPU и игроделы которым потом под это писать. Истошная борьба с API деланными под совсем иные реалии всех задолбала. В играх особенно злобно т.к. там активный вывод графики и куча вычислений - "их всё".

> Сам wayland по ходу будет не проще - уже тянет libinput

Ну я не против какой-никакой стандартизации input-а самой по себе. Без этого как-то тяжко.

> который тянет не отключаемый мультитоуч.

А это чем-то плохо? В смысле, оно весит сильно много, или чего? Или из каких соображений это надо отключать? Чтобы потом было побольше боли пониже спины при желании сваять какой-нибудь девайс с интерфейсов в который можно тыкать пальцем? Или что это дает, кроме шанса получить граблиной в лоб лишний раз?

> тем больше у меня подозрений, что останусь я на иксах.

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

> Пример программы?

Так сходу не вспомню. Как вы понимаете, я такие программы как правило предпочитаю на всякий пожарный сносить. Т.к. перспектива вызвать на десктопе клин графики до состояния когда я не могу задачу прибить за время которое меня не напрягает - не айс. Но прецеденты были и мне это не понравилось.

> С gtkperf тоже не тормозит.

Подозреваю что он основное время проводит в либе gtk, а не иксах. Т.к. цель по идее проверить производительность gtk. И, соответственно, это время больше приписывается таки процессу gtkperf-а? Общий смысл предъявы - такой что у иксов есть какие-то довольно дорогие вызовы. И если программа будет их агрессивно использовать - иксы могут начать трескать 100% проца, уперевшись по производительности в 1 ядро CPU. В результате может начать вся графика, system-wide. Вплоть до сложности отрисовки манагера задач или терминалки, что как-то не очень то айс. Поэтому со своей стороны я предпочту чтобы графическая подсистема как таковая не занималась сложным рендерингом и прочими вещами на которых можно надолго встрять. С точки зрения стабильности работы системы и отсутствия клинов.

> Нет его я не считал. Это уже проблема железа. От os это не зависит.

Вот это очень спорное утверждение. По факту это между железом и софтом. И софт вполне может быть в курсе как оно и даже рулить этим (как минимум, драйвер). У всяких APU и интеграта как я понимаю драйвер явно в курсе какой регион используется как "типа, VRAM" и это потенциально может быть использовано для zero-copy оптимизаций. Ну и остальным программам эта память под общие нужды недоступна, так что логично ее считать занятой, наверное. И это один из недостатков интеграта: оно не только откусывает память, но еще и нефиговый бандвиз по шине пихает. Как минимум для долбежа на экран силами CRTC.

...а тем временем AMDшники козыряют 4096-битной (!!!!) шиной памяти.

> С "-vo xv"  0.6% Xorg

Вот только xv - опционльное расширение. И далеко не любая программа в курсе об этом. А если программа не в курсе явно - будет намного менее привлекательное слайдшоу. А когда кто-то пишет программу - последнее что он хочет это прокостыливать это древнее дepьмецо. Я считаю что графическая система должна быстро работать по дефолту, а не как тридевятая опция при пятом приседании в позу лотоса програмером.

> У них там есть какие-то новый настройки для тиринга, но я не
> пробовал - почти всегда в fullscreen смотрю.

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

>> это должно работать как-то получше, а? :)
> Должно :) Но не всегда хватает времени и знаний починить или даже
> нормальный багрепорт написать.

Да там с всем этим vblank месиво какое-то. Возможна куча разных случаев (с композитором или без, etc). Драйвера не всегда идеально это обрабатывают, etc. Это периодически прокостыливают там и тут. Но реально сколько лет прошло, а работает как random(10).

А тут на пороге новые фичи стоят. Как то динамическая частота рефреша монитора. Ну то-есть если какой движок понял что зарендерить кадр за столько не судьба и будет дольше - он может и подольше, а его подождут. Минус тиринг, стало быть. Ну и потенциально меньше потребление энергии и бандвиз на шинах. Но фикус состоит в том что в линухе графический стэк к такому раскладу не готов чуть менее чем никак: там как я понял в куче мест допущения что FPS дисплея - нечто, буквально приколоченное гвоздями.