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

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

Оказывается, отсутствие тиринга — это фича, которая существует только в определённых комбинациях DE и настроек. Чем Wayland хуже, у него удалённый доступ тоже существует в определённых комбинациях DE и настроек?

1. Я не вчитывался в тред, но из того, что я видел, таких комбинаций там больше одной. Для вейланда такая комбинация ровно одна, если говорить про RDP.
2. Я ничего не говорил насчёт тиринга вообще. Я говорил только о тех фичах/проблемах, которые интересны/важны лично мне. И RDP тут фактически в пролёте.

Причём, заметь, поддержка RDP/Spice/VNC/Whatever в KDE/wlroots в перспективе возможна. В иксы уже никто ничего не добавляет, они совершенны.

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

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

Я не вчитывался в тред, но из того, что я видел, таких комбинаций там больше одной. Для вейланда такая комбинация ровно одна, если говорить про RDP.

Пока да.

Я ничего не говорил насчёт тиринга вообще. Я говорил только о тех фичах/проблемах, которые интересны/важны лично мне. И RDP тут фактически в пролёте.

Да. Я же не говорю, что ты не прав. Лично тебе не подходит Wayland — ну и бог тебе в помощь, мне не жалко. Лично мне не подходит X.

В иксах RDP не часть протокола

В Wayland, внезапно, тоже.

Какие недостатки X11 нужно устранить в первую очередь?

• Сделать API для нормального переключения раскладок клавиатуры, чтобы без вот этого всего балагана.

• Сделать композитор обязательным компонентом иксов (но тогда иксы перестанут быть иксами). Это решит кучу проблем и с тирингом, и с восстановлением разрешения после выхода полноэкранных приложений, и с управлением CSD приложениями, и с трансляцией отдельных окон  — в общем, много с чем. Появится состояние окна, упростится написание тулкитов и приложений.

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

В общем, по-любому X12 получается, несовместимый с X11. Концепция «у нас нет состояния окна, приложение рисует окно» немного устарела.

Концепция «у нас нет состояния окна, приложение рисует окно» немного устарела.

Наверное это был правильный подход для слабых компьютеров.

Разработчики QT ИМХО правильно поступили при разработке GUI.
Многое взяли из архитектуры GUI Windows и добавили свое.

Соглашусь.

И всё таки в динамичных и интерактивных штуках вроде шутера лучше иметь тиринг

Вы видео глянули? На это же смотреть невозможно!

Сделать API для нормального переключения раскладок клавиатуры, чтобы без вот этого всего балагана.

Немного сарказма.
API что поддерживает «древние» клавиатуры?
Например терминальных комплексов у которых клавиатура даже функциональных клавиш не имеет.

Интересный опрос.

Проголосовал: [x] Изоляция приложений [x] Другое

Другое: буфер обмена опустошается при закрытии программы, из которого в него было что-то скопированно.

Сделать композитор обязательным компонентом иксов

Мне, как человеку, не используещему композитный менеджер, эта идея кажется исключительно вредной. Все проблемы полноэкранных приложений мог бы решить https://keithp.com/x-ideas/pseudo-root/. А CSD это изначально дегенератская идея, пусть страдают дальше.

буфер обмена опустошается при закрытии программы, из которого в него было что-то скопированно

Кстати да, бесячая штука. Решается менеджерами клипборда, но не понятно, почему сервер не может сделать это сам, так как количество буферов все равно фиксировано

Еще бесят веб-макаки, которые думают, что поменять у текста фон - это все равно, что сделать его выделенным. И те, которые блокируют вставку средней кнопкой в свои формы.

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

Лучше иметь Freesync монитор, где тиринг просто невозможен даже с выключенным V-Sync. По сути Freesync решает обе проблемы: и тиринг и задержки от V-Sync.

Лучше иметь Freesync монитор, где тиринг просто невозможен даже с выключенным V-Sync.

Возможен, freesync сам по себе не убирает тиринг. Он решает проблему с задержкой при vsync-е.

Возможен, freesync сам по себе не убирает тиринг. Он решает проблему с задержкой при vsync-е.

При включенном freesync у тебя экран сам подстраивается под FPS окна, какой тут может быть тиринг? В каком случае?

При включенном freesync у тебя экран сам подстраивается под FPS окна, какой тут может быть тиринг? В каком случае?

Задача: у вас два окна, одно из которых обновляется с частотой 37 к/с, а другое — 41 к/с. Какая, по-вашему, должна быть частота обновления экрана в этом случае?

Задача: у вас два окна, одно из которых обновляется с частотой 37 к/с, а другое — 41 к/с. Какая, по-вашему, должна быть частота обновления экрана в этом случае?

Я говорил конкретно про игры, которые работают в fullscreen режиме.

Это решает проблему для полноэкранных приложений, но с окнами то это никак не поможет.

Это решает проблему для полноэкранных приложений, но с окнами то это никак не поможет.

Ну да, для окон и V-Sync сойдёт.

При включенном freesync у тебя экран сам подстраивается под FPS окна, какой тут может быть тиринг?

Надо ограничить фпс, чтобы он не выходил за g/free-sync зону (обычно ставят кап на 2-3 кадра в секунды ниже частоты монитора). На винде еще встречал тиринг в играх с работающим freesync-ом, но без vsync-а (под линуксом с фрисинком я под вейлендом играю).

Я говорил конкретно про игры, которые работают в fullscreen режиме.

Ну т.е. это даже не половинчатое решение.

Учитывая что у него всё падало в течении пары минут? Думаю тиринг был не главной его проблемой.

Это к теме X11 vs Wayland вообще не имеет отношения. А если бы не падало, то что?

Ну т.е. это даже не половинчатое решение.

Это отличное решение. Просто не тиринг является проблемой, а задержка. freesync с ней хорошо справляется.

Противопоставление X.org и Wayland теряет актуальность. Потому что Wayland был «не то что иксы», «это вам не иксы» только пока оставался красивой сказкой, о том как всем будет здорово жить при коммунизме. По мере превращения из идеи в реально существующий и работающий продукт, Wayland всё больше напоминает … да-да, иксы! Уже и тиринг реализовали. Забавно смотреть, как фанаты Wayland сменили пластинку с «тиринга не должно быть никогда!» на «в иксах неправильный тиринг, вот разработчики Wayland его сделали как надо».

А если быф не падало то возможно работало бы и экран не рассыпался бы.

Когда то давно я гонял сталкер ЗП в вайне, там не работала мышка и рассыпались некоторые модели и текстуры. Есть в таких условиях смысл измерять фпс и проверять тиринг?

А если быф не падало то возможно работало бы и экран не рассыпался бы.

С помощью какой магии? Тиринг-то был как раз пока приложение работало.

Адов тиринг возник как раз перед тем, как картинка начала скакать метров по 10 или по полсекунды. Там явно полный звиздец в динамических сценах. Почти наверняка вылет был связан с этим.

Точнее наоборот, обычно если есть проблема с поддержкой видео, частенько перед вылетом начинается полный звиздец с производительностью, время скачет, кадры рассыпаются.

Что только не придумают, какие теории не выдвинут, лишь бы адовый тиринг защитить…

Заметная часть проблем иксов базируется на том, что это протокол без сохранения состояния. Композитор — это такая программа, которая сохраняет состояние окна. Это совершенно не обязательно OpenGL-монстр со спецэффектами, полупрозрачностью и системными требованиями как у Half-life Alyx. Это может быть и достаточно скромная по возможностям программа.

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

Скажи, поддерживают ли иксы без композитора трансляцию одного окна?

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

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

ЗЫ в вейланд-сеансе - всё то же самое. Только ещё почему-то Caps как altgr не всегда работает :-)

Кстати, а как в этих ваших wayland-ах правильно выставлять масштабирование на HiDPI-мониторах? А то я в KDE-шке попробовал на одном мониторе увеличить масштабирование в 150% и получил такое омерзительное мыло, что не в сказке сказать, ни пером описать.

В сеансе Plasma/X11 стоит глобальное масштабирование в 150% и выглядит всё, ну, предсказуемо.

Ну, очевидно, что используются не иксовые средства, а какие-то костыли. И в вейланде тоже. И эти костыли одинаково криво работают.

Не знаю, это в KDE что-то нахимичили. У меня в гноме приложения Wayland масштабируются отлично, приложения X11 линейно (ну то есть с мылом). В KDE может, всё линейно?

Не знаю, это в KDE что-то нахимичили.

Использую на разных машинах 115%, 150%, 200%. Никакого мыла нет, только шрифты лучше выглядят.

Вот и помоги человеку.

И внезапно, но архитектура графики винды не менялась со времён наверное NT4

В NT6 (виста) поменяли и весьма серьёзно, см. WDDM. Дальше в основном допиливали уже.

Не знаю что тут можно сделать, разве что приложение/сеанс перезапустить с новыми настройками. У меня только для стима вручную GTK_SCALE указан.

Основное, наверное, неплавность(даже старая sdl игра Legend of Edgar, мне показалось, что скроллится фон плавнее) и дробное масштабирование(на 4к 27" хочется 175%, а не 200. и без мыла чтобы). Хотя и HDR бы хотелось, тогда следующий монитор можно было бы с HDR брать(лет через 10).

Ещё проблемой иксов вижу переключение раскладок по нажатию, а не по отпусканию(да, как в венде), из-за этого нельзя нажать что-то вроде Alt-Shift-1 для какого-либо действия и не переключить раскладку при этом.

Перешел бы на Wayland, но с моей невидией там слишком много глюков пока что. Основной это промаргивание фона, не знаю как назвать по другому, но как будто окно или пол окна на мгновение(кадр?) становится прозрачным. Причем это и в Sway и в KDE и в браузере и в играх, т.е. проблема скорее всего невидивских драйверов.

Перешел бы на Wayland, но с моей невидией там слишком много глюков пока что. Основной это промаргивание фона, не знаю как назвать по другому, но как будто окно или пол окна на мгновение(кадр?) становится прозрачным.

Пробовал?

Как исправить мигание изображения и прочие глюки отрисовки на связке KDE Plasma + Wayland + Nvidia

По первому пункту, у меня всё довольно свежее, насколько оно свежее в Gentoo конечно. По второму варианту тоже вроде не моё, по крайней мере, если плазма ещё может там что-то делать прозрачным, то в Sway дефолтном вроде ничего прозрачного нет. А вот KWIN_USE_BUFFER_AGE это вот не пробовал, сегодня попробую. Единственно смущает, что это для KWIN, а проблема одинаковая и в кедах и в sway. Надо будет ещё weston попробовать, для чистоты эксперимента.

Хорошо, если изменения и дальше будут минимальными и не ломающими. Но, не факт. Как компашке, что пилит Qt, зарабатывать на LTS версиях, если они никому не нужны, потому что ничего не сломали?

Да, насколько я знаю переписали всё с нуля. Но это была новая реализация старых api, с небольшими дополнениями.

Как минимум, в висте добавили композитор. В этот момент графика в Windows стала современной.

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

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

Xsgi? Еще были вcякие Accelerated X, но где их разработчики и код я не знаю …

да,эпично. Мы перенесли код из одного места в другое, разработчики патчей переходят на новый уровень :)

Жаль конечно, но вскрывает ту самую проблему что реально понимают как это все работает очень немногие, и увы с Вэйландом и прочим лет через 10-15 так же скорее всего будет (та же меса и drm subsystem поверх которой она работает тоже не hello world, разработчики nouveau подтвердят :/ )

есть еще такой тулкит как xfe, правда на нем мало чего написано. Ну или fltk. Переводить под них большие проекты наверное никто уже не будет, но глянуть что там и как устроено наверное попроще будет чем в современных больших тулкитофрэймворках.

к прелыдущему про пиксмапы - есть такое подозрение что их Х сервер, как и глифы, должен уметь кэшировать. И возможно часть тормозов - это перезагрузка пиксмапов из-за алгоритмов планировщика, который в glamor работает через OpenGL и может по ходу что-то теряет … Кстати да, вот еще - EXA делали именно с походом «выбросить все старое» и долго мучались с быстрой отрисовкой тех же глифов. Гламур …вроде как opengl-es использует но что-то мне подсказывает что ее в сновном пилили разработчики с толстыми десктопными дискретками, а потом … опять стало некому :). Т.е. архитектура ускорения внутри иксов тоже может играть свою роль.