Какие для Вас самые важные недостатки X-сервера и/или протокола X11?

Художникам, игрокам и кинозрителям равно как и обычным людям нужен виндоуз.

Виндоуз уже никому не нужен с его свистоперделками и партийными закидонами, поэтому вы видите массовое сваливание людей на Linux с 11й винды. Сваливание всех: игроков, художников, разработчиков. Потом ещё окажется, что в линуксах больше фич и игрульки работают быстрее чем в богоподобной винде. Нормизы, которые юзают винду как лаунчер для хрома понятно будут до конца на ней сидеть.

Ну собственно по HDR - ну мало оно кому надо, начиная с того что основная масса народа сидит на обычных IPS что в лаптопах что с десктопах с контрастом ну в лучших образцах 1500:1 то разговоры про HDR это только повод прибавить цену за поделие.

Сейчас пошли AMOLED ноуты в масспродакшен, так что возможно будет спрос а будет спрос- допилят.

Ну собственно по HDR - ну мало оно кому надо, начиная с того что основная масса народа сидит на обычных IPS что в лаптопах что с десктопах с контрастом ну в лучших образцах 1500:1 то разговоры про HDR это только повод прибавить цену за поделие.

Я больше скажу, народ сидит на TN гавне, где никакие цвета. У меня Full HD монитор с контрастом 3000:1. И всё это стоило около 12 т.р. Сижу и ржу над этим HDR.

массовое сваливание людей на Linux с 11й винды

Про массовое как-то вот не вижу. Игрокам тут делать пока нечего - в том же стиме который вроде как линуксоугоден далеко не все игры идут на линуксе (стимдек должен поидее это поправить). Художники и подобные креативщики в основном предпочитали мак. И продолжают его предпочитать. Разработчики - да, однозначно - учитывая что сейчас львиная доля разработки это всякое сетевое серверное и веб хозяйство и носимые устройства.

Другое дело что нам в России придется таки передвигаться в сторону линукса по понятной причине, ну и возможно потянется еще какой-то третий мир посмотрев на то что происходит здесь. Но это уже отдельная история.

Правильно ли я понимаю, что в опросе перечислены фичи вяленого, которых в иксах нет? Спецы, запилите плиз противоположную голосовалку: из ранее слышанного краем уха следует, что пунктов в ней поболе должно получиться.

Проголосовал «всё устраивает», но надо было два пункта: «всё устраивает» + «изоляция приложений».

Игрокам тут делать пока нечего - в том же стиме который вроде как линуксоугоден далеко не все игры идут на линуксе (стимдек должен поидее это поправить).

Вы не играете. Работает 90%, кроме игрулек с античитерскими зондами. Тот же Cyberpunk 2077 на линуксе работает чуть ли не лучше чем на винде. И это не смотря на то, что движок у игры какашка (в игре не работали лучи, DLSS работал).

Художники и подобные креативщики в основном предпочитали мак.

Художники были заменены на нейросеть, которая рисует ничуть не хуже.

Full HD монитор с контрастом 3000:1

«3000:1» как измерен? разница между экраном с выключенной подсветкой и максимально белым при 100% яркости?) реальные 3000:1 ни один ЖК не может, даже самые контрастные S-PVA.

Это потому, что gtk3 не юзает старые векторные фичи протокола X11. И гоняет в итоге Xorg растры не самым оптимальным образом, и без нормального сжатия, по сети. Этот тулкит не реализован по старым гайдлайнам x-ов. В отличии от старых, базирующихся на векторной графике и простых примитивах, тулкитов вроде motif, или нативных контроллов X11. Собственно, это не вина X-ов что серенькие, простенькие интерфейсы времён Win3x/Win95 людям стали не по душе, и они захотели разных графических излишеств, из-за которых тулкиты гонят в X11 красивые, но уже растровые, картинки вместо команд к X-протоколу на рисование простых геометрических фигур и линий, а также текста, в нужных местах. Гонять небольшой набор команд к X-ам по сети, которые на месте уже отрисуют из этих команд нужный интерфейс — было эффективно именно по протоколу X11. Гонять кучу растра, уже отрисованного современными тулкитами X-ам по сети с указанием, как эти растровые фрагменты склеивать на клиенте — оказалось не столь оптимально, с учётом того что X11 изначально пилили для эффективной передачи по сети команд на отрисовку интерфейса с помощью векторных возможностей X11. Собственно, использовать сложнейшую, написанную гениями во времена малого количества ресурсов, когда гонять растры с кучей деталей, и даже локально их отрисовывать, оконную систему для того, чтобы быстро отрисовать кучу растровых картинок в нужных местах поверхности — это как забивать гвозди микроскопом. С учётом того, что большая часть протокола и возможностей X-ов была именно на использование векторных возможностей и на особенности их использования в старых тулкитах, рассчитаны. Собственно, если признать, что современные тулкиты эти возможности не используют, и выкинуть всё это очень сложное, и когда-то необходимое, легаси, а вместо него воткнуть примитивные варианты с отрисовкой растровых изображений в нужных местах на поверхностях, и только те фичи, что нужны для современных тулкитов — от современных X11 останутся рожки да ножки. А ведь ещё приделать и другой способ передачи растров, с эффективным сжатием, базирующимся на наработках современных видеокодеков, ещё нужно будет. Такой рефакторинг сложных(реально куда более сложных чем wayland) X-ов, написанных в своё время очень умными людьми, в наше время сложней и затратней стал бы, чем написание Wayland с нуля. Собственно, новый протокол запилили только потому, что новые версии популярных тулкитов от смузихлёбов требовали вещей примитивных, которые проще для пущей эффективности написать с нуля, и не требовали всех тех старых и крутых наработок по старым векторным GUI, которые теперь никому не нужны. Под современные тулкиты Wayland оптимизирован(по своей архитектуре самой) лучше, чем X11. А X11 был оптимальным под старые тулкиты, которые в наше время мало кто юзает. Так и живём.

Если что, на Xt тулкиты можно натягивать xpm битмапы.

Да, всё правильно.

то у меня реально подгорает

А вот тут ничем не могу помочь :-) С точки зрения конечного пользователя — более высокая FPS в играх есть прогресс.

«3000:1» как измерен? разница между экраном с выключенной подсветкой и максимально белым при 100% яркости?) реальные 3000:1 ни один ЖК не может, даже самые контрастные S-PVA.

Так указано в спеках моего VA монитора. Хотите не верьте. У меня чёрный цвет по настоящему чёрный-чёрный. А яркие цвета на чёрном фоне выглядят офигенно. Я сразу увидел, что цветопередача качественная ещё в магазине, когда сравнивал с рядом стоящими IPS мониками.

Такой рефакторинг сложных(реально куда более сложных чем wayland) X-ов, написанных в своё время очень умными людьми, в наше время сложней и затратней стал бы, чем написание Wayland с нуля.

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

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

Проще выкинуть.

Не форкают по нескольким причинам:

• изначально X-ы писали очень умные люди с Phd из MIT для систем с очень малым количеством ресурсов, а потому GUI там было векторное и очень оптимизированное под довольно слабые системы, сейчас таких гениев, способных понять как они работают, оценить всё это, и как-то улучшить, найти не просто, а последние из таких сами взяли и ушли пилить Wayland, потому что требования новых тулкитов к графическому серверу сильно изменились с тех пор;
• собственно, тулкитописатели, они изменили модель работы тулкитов, и юзают теперь настолько малую часть возможностей X11, что нет смысла развивать огромный и сложный сервер только ради 0.001% возможностей, что используют современные тулкиты;
• даже если команда, что развивала бы X11, или даже сломала некоторые моменты совместимости, и пилила X12(были такие планы), столкнулась бы с жестокой реальностью, ведь тулкитописатели современные не юзают почти все возможности X11, не юзали бы и такие от X12, а значит работы по созданию форков X.org были бы заведомо бесперспективными, ну не будут же авторы X-сервера ещё и тулкит современный X-вый пилить своими силами, а если и будут, кто его юзать будет?

Вот-вот, проще выкинуть. Как бы жалко это не было бы делать(X11 действительно очень интересный артефакт своей эпохи), но суровую реальность не изменить.

Да-да, знаем мы эти современные тулкиты. GTK4 - это убожество, в котором выкинули половину фреймворка и опять сломали совместимость тем. Уже почти EFL quality.

Под sway да, завезли. Но, там юзается расширение протокола, которое в Gnome, к примеру, ещё не завезли. А Gnome известен тем, что не все расширения протокола реализуют, если им что-то не нравится, они это не реализуют, типа зачем надо…

Основные разрабы тулкита не парятся по поводу тем. Они решили, что достаточно дефолтной темы(светлый и тёмный варианты Adwaita), они уже libadwaita частью тулкита делают, и на этом всё. Так что с темами скоро будет та же беда, что в Windows/Mac OS X.

Основные разрабы тулкита не парятся по поводу тем. Они решили, что достаточно дефолтной темы(светлый и тёмный варианты Adwaita), они уже libadwaita частью тулкита делают, и на этом всё. Так что с темами скоро будет та же беда, что в Windows/Mac OS X.

Да на хрен этот GTK4 никому не нужен. На нём приложений 2,5, хотя GTK4 уже давно существует. Все уже давно решили форкать GTK3, потому что титаник пошёл на дно. Никто не будет переписывать свои приложения на сомнительный фреймворк. Фреймворк wxWidgets уже отказался поддерживать GTK4, потому что он «концептуально отличается» даже от GTK3. Куча приложений до сих пор висит на GTK2. И никуда они не денутся, всё равно придется форкать GTK3 и писать библиотеку, чтобы как-то поддержать старый GTK2.

И проблема добавления новых фич в иксы — да тот же HDR, в том, что все эти фичи нужно будет добавлять в код

Я тебя удивлю, нужно будет только поменять формат пикселей в композиторе, да и всё. Это не настолько уж и сложно.

Все уже давно решили форкать GTK3, потому что титаник пошёл на дно.

Покажите где эти форки GTK 3?

Я тебя удивлю, но нет. Это как раз путь получить либо слишком тёмные SDR приложения, либо вырвиглаз, которого ты так боишься.

Для нормальной поддержки HDR требуется как минимум, регулировка баланса SDR приложений в HDR пространстве, а в идеале — возможность для приложения устанавливать регионы, в которые оно выводит HDR контент.

Тебе сложно судить о том, что такое HDR, потому что ты его не видел.

Почти всё чекнул кроме тачей и нестандартных устройств ввода, и всё это реальные проблемы. Ещё в опросе не хватает:

• Ограничение на количество клиентов
• Ограничение на максимальное разрешение виртуального рабочего стола

Покажите где эти форки GTK 3?

GTK3 пока ещё живёт. Если начнут прикрывать, народ форкнет.

Для нормальной поддержки HDR требуется как минимум, регулировка баланса SDR приложений в HDR пространстве, а в идеале — возможность для приложения устанавливать регионы, в которые оно выводит HDR контент.

Мониторы умеют выводит строго только один формат пикселей, например либо строго 8 бит на пиксель или 10. Никогда такого не было, чтобы кусок экрана, например 8 бит цвета, а остальное 24 бит. Всё равно 8 бит конвертируется на стороне драйвера, а на экран выводится уже 24 бит. Поэтому в HDR режиме все пиксели экрана будут в HDR пространстве (SDR -> HDR). По другому никак не сделать. Может это и не нужно, потому что HDR только в игрульках и кинце, где 100% будет полный экран. Наверное создатели HDR не думали, что его будут использовать где-то по мимо телевизоров.

GTK 2 что-то не форкнули.

GTK 2 что-то не форкнули.

Но были попытки написать совместимую альтернативу https://github.com/thesquash/stlwrt Жаль что автор на это забил. И да, GTK3 не был настолько плохим как GTK4.

P.S. Есть ещё какой-то форк GTK3 где вырезан CSD и прочие какахи, но я его не нашёл, забыл добавить в закладки.

Да. В идеальном случае, когда тулкиты непосредственно используют иксовые команды отрисовки, сетевая прозрачность иксов лучше.

Поэтому в HDR режиме все пиксели экрана будут в HDR пространстве (SDR -> HDR).

Вот именно. А пользователь может при этом запустить как HDR, так и SDR приложение. Соответственно, кто-то должен обеспечить корректный маппинг SDR в HDR. Кто-то должен обеспечить, чтобы окно SDR поверх окна HDR отображалось нормально, ведь SDR приложение вообще ни разу не в курсе ни про какой HDR, оно так и будет оперировать 8 битным цветом.

Может это и не нужно, потому что HDR только в игрульках и кинце, где 100% будет полный экран.

Даже в кинце не обязательно полый экран. И приложению надо выводить кино в HDR, а контролы — в SDR. А если в процессе просмотра кинца пользователь захочет альт-табнуться в браузер или в телеграм?

Поддержка HDR не так проста, как ты думаешь.

И тут врываюсь я с предложением затестить ssh -X ip.ip.ip.ip links2 -g https://www.linux.org.ru/.

Голые иксы. Никаких тулкитов. Всё как мы любим.

Классика: царь иксы хорошие, бояре тулкиты плохие.

И это так. Тулкиты перестали полагатся на возможности иксов из-за их стагнации

Ну так царь впал в маразм от старости, что бедным боярам то делать.

которые икса в силу малолетства своего не видели

«Икса не видели» и «бабу не нюхали». Аргументация действительно достойная провинциального администратора Solaris застрявшего в 2007 году.

И это так. Тулкиты перестали полагатся на возможности иксов из-за их стагнации

Ага, в особенности Electron. /sarcasm

Я нифига не понял.

Бывает. А проблема эта внезапно существует независимо от того, понял ты её или нет: А вы помните бесячий баг иксов, который всегда раздражал?

Честно, за всю жизнь ни разу не встречал.

Значит у тебя недостаточно продолжительный опыт использования иксовых окружений. Кстати эта иксовая проблема, равно как и упомянутая уже невозможность переключения раскладки при открытых контекстных меню проистекают всё из того же дурацкого монопользоного захвата ввода. Это серьёзнейший архитектурный баг, который за 40+ лет никто так и не удосужился пофиксить.

Это серьёзнейший архитектурный баг, который за 40+ лет никто так и не удосужился пофиксить.

Наверное определённо какая-нибудь хрень, которая встречается только в какой-нибудь гномосячине. Потому что я реально не встречал таких проблем. Даже в те времена, когда юзал jwm под FreeBSD.

равно как и упомянутая уже невозможность переключения раскладки при открытых контекстных меню проистекают всё из того же дурацкого монопользоного захвата ввода. Это серьёзнейший архитектурный баг, который за 40+ лет никто так и не удосужился пофиксить.

Подозреваю что исправить там не сложно, но начинается нытьё что тогда реализация перестанет соответствовать спецификации. Меня удивляет как разработчики X11 держутся за соответствие каждой мелочи со спецификацией. Даже за попиклельный рендеринг старыми векторными командами держутся горой. Не понимаю зачем это надо, это уже перебор. У Microsoft и то не такие строгие требования и у разных версий Windows есть различия в поведении оконной системы.

Соответственно, кто-то должен обеспечить корректный маппинг SDR в HDR. Кто-то должен обеспечить, чтобы окно SDR поверх окна HDR отображалось нормально, ведь SDR приложение вообще ни разу не в курсе ни про какой HDR, оно так и будет оперировать 8 битным цветом.

Всё это очевидно в видеодрайвере будет делаться. Но тут всё равно как с микшированием звука получится, что в итоге на экран будет выводиться только HDR.

Даже в кинце не обязательно полый экран. И приложению надо выводить кино в HDR, а контролы — в SDR. А если в процессе просмотра кинца пользователь захочет альт-табнуться в браузер или в телеграм?

8битный рендеринг всё равно либо тулкитом, либо видюхой конвертируется в 24 бит. С HDR так же будет, по другому ты никак не сделаешь.

Список странный, ибо большинство вещей в нём на самом деле не являются проблемами, а вот теперь про настоящие проблемы протокола:

Тут есть ещё очень важный момент. Проблема «Устаревшая кодовая база, с которой сложно работать» обозначенная в опросе недостаточно разъяснена, а жаль!

Вот совсем-совсем недавный случай: В ядре нашли костыль, заточенный под процессы Xorg

Вместо того чтобы взять и подфиксить иксы разработчики взяли и внесли настолько смешной и убогий иксовый костыль прямо в… ядро Linux. При этом хоть бы один луддит который пишет всякие пространные посты здесь облизывая иксовые копролиты сказал хоть что-нибудь вроде «ну, ребяяят!». Ни-ни. Для них «икс» – священная корова. А те кто «икса не нюхали» хипстеры и смузихлёбы.

Так вот, дело-то всё в том, что иксовая кодовая база и архитектура настолько отвратная, что разработчикам проще залезть в ядро Linux и исковеркать его убожеским костылём, чем залезть собственно в код иксов, разобраться и сделать эти правки там.

А когда случается подобное, это называется метастазированием. Когда нездоровая кодовая база (иксовая в данном случае) заражает форменным говнокодом здоровую кодовую базу (ядра Linux).

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

Всё это очевидно в видеодрайвере будет делаться.

А настраивать как? Тоже в видеодрайвере?

Не, ну ради того, чтобы не трогать кодовую базу исков, может так и надо сделать.

8битный рендеринг всё равно либо тулкитом, либо видюхой конвертируется в 24 бит.

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

А в исках нет поверхностей, увы.

Вот совсем-совсем недавный случай: В ядре нашли костыль, заточенный под процессы Xorg

И теперь Wayland фанатики страдают от недостатка внимания: «Нееет! Это должны были быть мы!».

Так вот, дело-то всё в том, что иксовая кодовая база и архитектура настолько отвратная, что разработчикам ПО проще залезть в ядро Linux и исковеркать его убожеским костылём, чем залезть собственно в код иксов и сделать эти правки там.

Ну дык, исправили же.

А когда случается подобное, это называется метастазированием. Когда нездоровая кодовая база (иксовая в данном случае) заражает форменным говнокодом здоровую кодовую базу (ядра Linux).

Знаешь сколько Wayland своим говнокодом программ заразил? В Firefox без поддежки Wayland VA-API не работает на иксах. Причём тут Wayland не понятно, но это факт. А могу тебе про другие редхатовские поделки рассказать. Ппшпшпаудио и soystemd. Надо? Хотя systemd хотя бы нормально работает. А virgin Pulseaudio выкинули и заменили на гигачад-Pipewire. Wayland ждёт аналогичная судьба.

Если бы все эти баги было несложно исправить – никто бы не стал велосипедить новый протокл. Максимум запилили бы новую реализацию X11, не связанную с кодовой базой Xorg.

Подозреваю что исправить там не сложно, но начинается нытьё что тогда реализация перестанет соответствовать спецификации. Меня удивляет как разработчики X11 держутся за соответствие каждой мелочи со спецификацией. Даже за попиклельный рендеринг старыми векторными командами держутся горой. Не понимаю зачем это надо, это уже перебор. У Microsoft и то не такие строгие требования и у разных версий Windows есть различия в поведении оконной системы.

Был помнится однажды такой проект как MinGW, порт компилятора GCC для Windows. Его разработчики тоже держались за соответствие каждой спецификации как кое-кто держится посиневшими руками за «трон». Что случилось дальше? Многим разработчикам проекта стало тесно действовать в рамках этих спецификаций и они создали форк MinGW-w64, который затмил MinGW и сегодня представлен во всех дистрибутивах, используется значительным большинством и рекомендуется к этому использованию. Ну а в MinGW осталось 2.5 землекопа, которые всё так же продолжают посиневшими руками держаться за спеки.

Fin.

Единственное преимущество MinGW было в том, что я, например, мог взять какой-то современный код, скомпилировать его этим компилятором и он будет работать в Windows 95 и Windows 98:

https://baat.exlmoto.ru/~exl_lab/screens/win98_1.png

Это конечно здорово и интересно для всяких исследователей старых OS и прочих ностальгантов, но бизнесу и современным прикладным разработчикам точно не нужно.

И что, приложения, написанные на электроне, легко пробрасываются по сети? Электрон не гоняет битмапы и ничего не рисует, но использует иксовые команды отрисовки граф. примитивов?

И что, приложения, написанные на электроне, легко пробрасываются по сети? Электрон не гоняет битмапы и ничего не рисует, но использует иксовые команды отрисовки граф. примитивов?

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

Это потому, что gtk3 не юзает старые векторные фичи протокола X11. И гоняет в итоге Xorg растры

На самом деле нет. Отрисовка контролов в GTK+2 и GTK+3, если они используют backend’ом Cairo, который в свою очередь использует backend XRender выполняется графическими вектороподобными примитивами, которые в теории и должны гонятся по сети.

Я когда-то тоже считал что там гоняются сырые битмапы, но вот здесь i-rinat меня поправил:

Три проблемы Вайланда, как фиксить? (комментарий)

Я проверил простенькое GTK+3 приложение как-то так:

x11trace -n gnome-calculator | grep trapezoids

И действительно в лог посыпались графические примитивы, пресловутые трапезоиды Кита Паккарда.

На самом деле нет. Отрисовка контролов в GTK+2 и GTK+3, если они используют backend’ом Cairo, который в свою очередь использует backend XRender выполняется графическими вектороподобными примитивами, которые в теории и должны гонятся по сети.

И теперь всё это выкинули в GTK4 и заменили на не-cairo hardware рендеринг, который мыльцо и артефачит через раз из-за многочисленных багов в $yourdrivername$.

Наверное определённо какая-нибудь хрень, которая встречается только в какой-нибудь гномосячине. Потому что я реально не встречал таких проблем.

Я вот в той своей теме ещё не поленился взять и проверить наличие этого иксового бага в православном RHEL 4 вышедшем в 2005 году, когда в ходу был ещё святой GNOME 2:

https://baat.exlmoto.ru/~exl_lab/movies/X11_Screens_PrintScreen.webm

Как видно, иксовый архитектурный баг с монопольным захватом ввода был ещё 20 лет назад.

Как видно, иксовый архитектурный баг с монопольным захватом ввода был ещё 20 лет назад.

Возможно что-то аналогичное в Windows 1.0-3.11 есть, не уверен. Вроде нет.

Возможно что-то аналогичное в Windows 1.0-3.11 есть, не уверен.

Если знаешь как проверить, можно проверить тут: https://archive.org/details/windows-3.11-sgvm