Если что, то поскольку Wayland приложение в любом случае готовит картинку для помещения в буфер, можно эту картинку гонять по сети вообще по любому протоколу. Не удивлюсь, если Red Hat уже работает, например, над интеграцией SPICE.

Только это придётся впиливать в каждый тулкит отдельно.

Ну собственно, поскольку у ред хат есть вполне конкретный the toolkit, для себя они проблемы не видят.

Хотелось бы иметь адекватную архитектуру, в которой можно на удалённой машине поднять «абстрактный» (безголовый) графический сеанс, который там просто работает постоянно, и в который можно коннектиться клиенскими машинами, превращая их в терминалы. Графический tmux, короче.

Как это сделать при помощи Xorg, xpra, нескольких костылей и двух упаковок скотча — более-менее понятно.

Как это будет сделано при помощи вейланда и несуществующего пока сетевого протокола — совсем не ясно.

Где-то там в интернетах были видео, в которых на ARM-одноплатниках Wayland-композиторы были заметно быстрее X.Org.

Небось строго в отдельно взятых приложениях и небось сравнивали с X.org, на котором GTK крутился с вяленым с чем-нибудь полегче.

Так вот: X.org это всего лишь одна из множества реализаций X-сервера (их реально дофига). Реализация X-сервера обеспечивает взаимодействие между X-клиентом (приложением) и железом. Как реализован X-сервер - дело десятое. X.org хорош тем, что он модульный, поэтому отлично подходит для десктопа. Для обеспечения поддержки того или иного железа в случае с X.org сервер переписывать не надо - надо всего лишь драйвер подгрузить. Во времена распространения XFree86 под каждую видеокарту своя реализация X-сервера была, а уж потом решили не велосипедить и один X-сервер на всё десктопное оставить с подключаемыми драйверами, благодаря чему дополнительная унификация получилась без поломки совместимости и урезания возможностей - приложения всё так же работают с любым X-сервером.

Протокол тут вообще не к месту.

А ты со всей это кухней знаком, да? Есть опыт разработки X-клиентов?

Работа на широком спектре железа без потери возможностей - это неоспоримое преимущество. Тебя правильно анацефалом анонимус назвал.

Хотя бы от зоопарка избавимся.

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

Только это придётся впиливать в каждый тулкит отдельно.

Необязательно, достаточно переделать libwayland-server. Приложению ведь не важно, как работает композитор — рендерит он полученное окно локально или отправляет за океан?

Впрочем, мы сейчас гадаем на очень жидкой кофейной гуще.

А ты со всей это кухней знаком, да?

Нет. Мы уже в соседней ветке это выяснили. Не трать время.

Преимущество X11 уже много раз озвучивали. Недостатки реализаций и протокола - тоже. Но почему-то вместо устранения недостатков идиоты пошли делать вяленого. Впрочем, не почему-то, а потому, что идиоты. Они изначально не определились, что должна уметь оконная система и в каких частях какие обязанности должны исполняться. В результате получили вяленого франкенштейна, который уже 10 лет разрабатывают и который не поспевает даже за десктопом десятилетней давности, а X.org идёт в ногу со временем (осталось несколько мелких проблем решить только вроде автоматизации работы с дисплеями с разными dpi) даже без изменения протокола.

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

И на сцену выходит Jolla с Sailfish, на которую показывают пальцем, когда речь заходит о готовности вяленого.

jolla сейчас своё говнецо пытается в сколково напарить. лучше бы она не выходила на сцену, а дома посидела.

Это ты врёшь напару с лёней. Везде всегда говорили про скорость загрузки, когда о systemd речь заходила. Об остальных «преимуществах» редко что говорили. С вялендом то же самое - постоянно говорили, что иксы тормозят, что производительность в вяленде при любых условиях выше, что энергопотребление ниже, так как сетевой прозрачности и всего остального нет. Тесты показали обратное.

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

Необязательно, достаточно переделать libwayland-server. Приложению ведь не важно, как работает композитор — рендерит он полученное окно локально или отправляет за океан?

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

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

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

Разработчики сразу писали: ковряться в кишках X.org нам больше не охота, вот вам API на композитор фреймбуфера вместо оконной системы, дальше любитесь сами. Ну может бюджет не выделили людям на разработку иксов, экономика должна быть экономной.

Вообще-то это не так. То, что они неосиляторы - это понятно. X-сервер и в одиночку написать можно, если на то пошло. Проблема в том, что они напрочь убивают унификацию и этим дают только недостатки. Про деньги на разработку - это вообще чушь. Изначально такой вопрос не стоял.

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

Это да. Если захотим ускориться :-) Ключевое слово — если.

Если же не захотим, т.е. будем реализовывать VNC или RDP, то поддержка со стороны тулкита не нужна.

Чтобы ред-хат что-то взяла да с первого раза спроектировала, да с первого раза внедрила...

Используя Wayland можно взять и заменить сам протокол передачи картинки просто вот взяв и заменив. Так что, может, с третьего раза? :-)

Даже если 3-5%, то ничего хорошего в этом нет, так как ничего хорошего при этом не даётся, а урезаются возможности.

Какое еще копирование во фронт-буффер? Смена буфера - это смена указателя на него.

А то, что от systemd в основном проблемы, а не польза.

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

наркоман чтоле

тесты были XWayland vs X.org. Нативного вяленого софта пока только гном.

А достоинств масса, например возможность нормальной работы с несколькими мониторами, имеющими разную плотность пикселей.

Это достоинство конкретного комопзитора. Фактически конкретного графического сервера. Иксы так тоже могут при наличии соответствующего графического сервера. Да и в X.org можно разным мониторам назначить разный dpi.

Ну, например, выбрать не modesetting драйвер, и отключить там опцию TearFree.

А ещё можно себе палец дверью прищемить...

Это проблемы не сервера, это проблемы протокола. В нём нет синхронизации, он ориентирован на рисование сразу же. Нет гарантированного способа нормально рисовать.

То есть, то, что протокол даёт большую свободу в формировании изображения - это проблема протокола?

Реч идет о внутренней организации видео адаптера. Для приклодного уровня есть абстракции - SWAP BUFFERS, и PRESENT как они реализованы в железе, никто кроме самих вендеров не знает. Очень часто фронт буфер из которого формируется сигнал для монитора апаратно отделен от GPU и висит на своем отдельном контроллеры. А сам буфер представляет из себя двупортовую память в которую GPU копирует содержимое текущего DRAW буфера. Именно по этой причине в OpenGL/DirectX очень проблемотично получить содержимое текущего фронт, эта функция работает очень медленно - на некотором железе вообще не работает.

Список рабочих эксплойтов для иксов будет гарантированно больше, чем для вялендоподелий, так как X.org несоизмеримо популярнее.

В линуксе графический медленней чем в Windows не потомучто X11 - а потомучто он UserSpace и работает по IPC. А в Windows он встроен на уровне ядра OS.

По итогам в линуксе не медленнее. Низкий уровень всё равно нивелируется юзерспейсом везде.

То есть, то, что протокол даёт большую свободу в формировании изображения - это проблема протокола?

Да. Сравни, например, машинные коды, Си, Си++ и что-нибудь высокоуровневое на выбор.

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

Проблема — когда тулкиту/приложению зачем-то нужно обращаться ко всяким API, помнить информацию о мониторах и вообще делать работу композитора, чтобы всё корректно отрисовывать.

Я тебе открою страшную тайну: тулкиты именно для этого и существуют.

Ну, Quasar всё-таки личность тут известная. Он был странный, когда я на этот форум пришел. И вот сколько лет прошло, а он всё такой же странный. Никаких изменений. По нему калиброваться можно.

Если же не захотим, т.е. будем реализовывать VNC или RDP, то поддержка со стороны тулкита не нужна.

Если использовать RDP как VNC (а зачем?) — то может и не нужна.

А если почитать вот этот документ, то можно сделать много открытий: https://msdn.microsoft.com/en-us/library/dd302831/

А возможно Xorg не такой плохой, что не даёт себя обогнать?

X.Org это не что-то неизменное. Он становится лучше, потому что его достаточно активно дорабатывают. 2D графика стала намного быстрее благодаря GLAMOR и modesetting. Я как-то на это раньше не обращал внимание, но несколько месяцев на intel+sna наглядно показали, что с modesetting гораздо приятнее. Сравни размер кодовой базы драйверов modesetting и intel. Intel во много раз больше. И тормознее при этом. Старая архитектура драйверов не очень-то хорошо работает на современном железе.

И знаешь, очень похоже на то, что на Wayland отрабатывают некоторые идеи, которые затем портируют в X.Org. Так пользу извлекают все.

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

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

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

Вот эти тесты показали, что нифига не лучше, чем на иксах, всё работает. Зато проблем добавляет. А из нативного софта - достаточно на Qt или GTK собрать что-нибудь. Вот тебе и нативный софт на вяленого.

В соседней ветке мы выяснили, что ты несёшь чушь.

Не я тут странный, а странные те, кто отождествляют «вопрос не рассматривался» с «намеренно заложенный недостаток».

я задолбался бороться с тирингом на X.Org в полноэкранке в различных приложениях

В композитном режиме нет никакой разницы между полноэкранными и неполноэкранными окнами. Тиринг может появляться только если менеджер окон отключает композитинг для последних, чем страдает, например, GNOME Shell (Mutter). X-сервер тут не при чём.

Вчера я думал, что ты шлангуешь, но ты, похоже, просто не понимаешь.

Вот ты выдумал «многоуровневый захват ввода». А зачем он? Это какая-то твоя личная хотелка. Сам посуди. X11 не очень хорошо дружит с концепцией всплывающего меню. Для того, чтобы это исправить, добавлен костыль в виде монопольного захвата ввода. Из-за монопольного захвата ввода ломается обработка глобальных хоткеев. Это проблема, и её нужно решать. И ты её предлагаешь решать как? Добавлением ещё костылей — «многоуровневый захват ввода».

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

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

После продолжительного садомазо с калибровкой сенсорного экрана в гнуме3 из-за вяленого дерьмеца и либинпута от всего сердца хочу пожелать сгореть в аду всем троим. В чистых иксах все делается с полпинка и по-человечески, а не колдованием с матрицами и правилами udev.

Wayland vs Xorg in low-end hardware

Если в Xorg использовать композитный менеджер окон, будет ровно так же, как в Wayland.

Кроме того, как человек, пишущий под Raspberry Pi графические приложения, я знаю, почему они в этом видео выставили не FullHD-разрешение. :) В нём любой композитор выдаёт максимум 20 FPS, в то время как Xorg особых проблем не имеет. Плюс X-сервера как раз в том, что там композитинг опционален.

А зачем он?

АПВС?

И всё, все вокруг — шланги, потому что не разделяют твою единственно верную точку зрения.

Чтобы я тебе рассказал, почему нужно отделять механизм от политики, а ты опять выдал перл типа «думаешь, что все вокруг — шланги»? Уволь.

xlib

Давно уже все современные тулкиты XCB используют.

Недостаточно современный тулкит: https://github.com/GNOME/gtk/blob/master/gdk/x11/gdkwindow-x11.c

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

Карго-культ.

а ты опять выдал перл типа

Карго-культ.

Не подвёл. Молодец.

парочка неосиляторов X.org решила написать свой кусок говна

Т.е. между реальной свалкой костылей и прочего дерьма, в котором могут разобраться всего 2 человека на весь мир, и кодом, в котором хотя бы есть комментарии, который специально создавался для того, чтобы хотя бы в нем мог разобраться каждый, ты выбираешь первое? Ну...мсье знает толк в извращениях. X.org работает, да. Вот только поддерживает его становится все сложнее. Слышал об этом? Хотим мы этого или нет, но Вяленый де-факто будет популярнее, просто в силу того, что в куче металлолома под названием X.org просто станет всем влом разбираться.

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

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

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

Я тут поною про оффтопик

Переписывать старый софт всегда стоит.

Ога-ога, сферическим разработчиком в вакууме, который не спит, не ест, ошибок не делает, денег не просит и, к сожалению, не существует.

Пока у нас тут корабли срача бороздят просторы ЛОРа, передо мной встала задача помочь жене с правкой doc-файлов. Я один файл открываю — там в списке стилей есть кнопка «Очистить всё», открываю другой — кнопки нет. Шел XXI-й век, программисты не могли найти убежавшую кнопку...

Так что не надо переписывать софт, пока он работает. Можешь не писать код — не пиши.

а тесты показали что иксы равны иксам. А у вас претензии типа «если „5“ больше чем „1“, то почему тогда „1“ = „1“? шах и мат, вяленд!»