LINUX.ORG.RU

Сравнение сеансов GNOME на основе Wayland и X11

 , ,


1

5

Портал Phoronix провёл серию сравнений сеансов GNOME на базе Wayland и X11. Для тестов использовались дистрибутивы Fedora 27 и Ubuntu 17.10. Существенной разницы в производительности игр, энергопотреблении и объёме занятой оперативной памяти обнаружено не было.

>>> GNOME 3.26: Wayland vs. X.Org Performance

>>> Wayland vs. X.Org Gaming Tests

>>> Intel Graphics Performance

anonymous

Проверено: Aceler ()
Ответ на: комментарий от anonymous

пример - гном. На иксах все дерганное, анимация проседает до ~15 кадров\с, скролл тормозной. На вяленом анимация стабильно 60 кадров\с, все плавно, если не считать рандомных дерганий и одного угребищного бага который все портит: https://bugzilla.gnome.org/show_bug.cgi?id=745032

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

EXL ★★★★★ ()
Ответ на: комментарий от anonymous

https://bugzilla.gnome.org/show_bug.cgi?id=745032

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

anonymous ()
Ответ на: комментарий от sudopacman

Предположим, я разработчик и использую Qt. Сколько раз мне бы пришлось переписать своё приложение за период существования Qt 5?

Пришлось бы. Я как минимум натыкался на ломание API/ABI несколько раз. Из самого эпичного изменение режима работы qDebug(), который даже на ЛОРе отметился.

У Qt не слишком строго соблюдается совместимость:

https://abi-laboratory.pro/tracker/timeline/qt/

GTK+ в этом плане на голову выше:

https://abi-laboratory.pro/tracker/timeline/gtk /

EXL ★★★★★ ()
Последнее исправление: EXL (всего исправлений: 2)
Ответ на: комментарий от EXL

Ты в Крыму что ли живёшь?

Я живу в столице Казахстана Астане. Казахстан - это независимое суверенное государство в составе СНГ (Евразия) на планете Земля...

anonymous ()
Ответ на: комментарий от anonymous

Хорошо, хорошо. Можешь из Астаны прилететь в Новосибирск и купить ноутбук даже не с FullHDI, а с 2K HiDPI экраном. Здесь их много и они довольно доступные.

Ну или по почте заказать.

EXL ★★★★★ ()
Последнее исправление: EXL (всего исправлений: 2)

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

anonymous ()
Ответ на: комментарий от sudopacman

Реально есть много программ для iOS, у которых нет даже вменяемых аналогов под Android?

Ага. Например, в My Little Pony щас выкатили дополнительную реальность.

Естественно, в ведройде это ждать и ждать.

fornlr ★★★★★ ()
Ответ на: комментарий от anonymous

Легко делать такие выводы когда не разбираешься в матчасти, да?! Вы хоть причину этих «тормозов» занете? Ну вот и не надо тут ля-ля. Вяленый лишь прослойка между ядром и композитором. И если у вас что-то там медленно работает, то наверное дело в ваших «золотых» руках?! Может это повод задуматься вам и всем тем, кто пишет о том, в чем совершенно не разбирается

anonymous ()

Я надеюсь тут все понимают, что вейленд лишь прослойка между интерфейсом и дисплейные сервером? Вейленд лишь клиент, как x11. С тем же успехом можно выкинуть x.org на его место сделать mutter или Kwin. Так вот к чему я. Не важно, вяленый или х11. Важно то какой дисплейный сервер используется. С тем же успехом гном могут написать свой клиент под x11 или mutter. Если у вас целый зоопарк дисплейных серверов, то извольте ловить глюки и медленную работу графики. Графическая подсистема большая. Ее нужно упростить. И вейленд лишь винтик в большой цепочке.

anonymous ()
Ответ на: комментарий от anonymous

Я надеюсь тут все понимают, что вейленд лишь прослойка между интерфейсом и дисплейные сервером?

Нет, я не понимаю. Что это еще за дисплейный сервер, для которого вяленый прослойка между интерфейсом и дисплейные сервером?

Вейленд лишь клиент, как x11.

Час от часу не легче. Вейленд и x11 сами по себе дисплейные серверы. Ну ладно, я еще представляю, что можно сделать транслятор протокола X11 который бы работал с вяленым, или наоборот. Но дисплейный сервер, который бы был клиентом к другому дисплейному серверу - это уже за гранью разума.

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

Занятное упрощение получается. К сложному добавили еще сложное, чтобы сделать проще.

zloy_starper ★★ ()
Ответ на: комментарий от sudopacman

В иксах — нельзя. Делать это через тулкит — костыль.

Я так понимаю, аргументов (кроме «Я так считаю») не будет? Я с таким же успехом могу заявить, что это не дело композитора — следить за DPI.

есть ли принципиальная разница?

Да.

Я в исходном своем комментарии специально выделил слово «принципиальная». Напомню, речь шла о посылке тулкиту сообщения о том, что в отрисовке надо что-то менять. Кто ему это сообщение пошлет — это непринципиально, по-моему.

Тулкит не должен следить за разрешением мониторов.

Вот как-то все время этим занимался, а потом устал, бедняжка. Или ему создатели wayland следилку оторвали (см. начало третьего абзаца по ссылке)? Ты в этом своем тезисе про тулкит не путаешь причину и следствие?

Система ему и так сообщает коэффициент масштабирования. Просто в вяленом его можно динамически менять.

А в иксах нельзя? Через Xrandr, например. Не дело тулкита знать о расположении мониторов — пусть за этим следит WM. В конце концов, это его прямая обязанность — знать, какое окно где расположено. Он же и инициирует посылку сообщения клиенту о том, что окно (или его часть) переехало на монитор с другим DPI.

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

Как он определит, поддерживает приложение масштабирование или нет? А то «заапскейлит» пользователю какую-нибудь Доту2 — то-то весело будет.

Почему до тебя это сразу не дошло?

Продолжай в том же духе. Это же так удобно — считать всех окружающих идиотами, правда?

mamboo ()
Ответ на: комментарий от i-rinat

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

Какие ещё плюшки? Разрабы вейланда обсирали хорг за то, что он комбайн и клятвенно обещали, что они не допустят такой ошибки

anonymous ()
Ответ на: комментарий от FiXer

Wayland уже готов, он используется в SailfishOS, никто не мешает его использовать в embedded. И никто не мешает разработчикам адаптировать свои проекты под Wayland (чем некоторые из них и занимаются). В Fedora с GNOME по умолчанию Wayland-сессия.

sudopacman ★★★★★ ()
Ответ на: комментарий от ugoday

Иди почитай

А что ещё можно ответить тому, кто думает, что Wayland == DE, использующие Wayland?

Хотя зачем вообще я пытаюсь спорить с человеком, который верит в заговор RedHat против линукса?

sudopacman ★★★★★ ()
Последнее исправление: sudopacman (всего исправлений: 1)
Ответ на: комментарий от sudopacman

который верит в заговор RedHat против линукса?

ugoday: Корпорация стремится увеличить прибыль и монополизировать рынок.

sudopacman: Ололо, да где же это видано, чтобы корпы так поступали, какможноверитьвтакуючушь?!!!

ugoday ★★★★★ ()
Ответ на: комментарий от khrundel

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

ugoday ★★★★★ ()
Ответ на: комментарий от mamboo

аргументов

  1. Оконная система уже отвечает за работу с дисплеями, DPI и т. п. Зачем внедрять в тулкит ещё раз то, чем она занимается?
  2. (Уже который раз повторяю одно и то же.)
    Нельзя заставить все тулкиты/приложения (как минимум потому, что разработка некоторых из них уже прекращена) поддерживать HiDPI и реализовать то, что вы предлагаете.

Я в исходном своем комментарии специально выделил слово «принципиальная». Напомню, речь шла о посылке тулкиту сообщения о том, что в отрисовке надо что-то менять. Кто ему это сообщение пошлет — это непринципиально, по-моему.

Только вы с devzero предлагаете вариант, когда тулкит это сообщение посылает себе сам.

Вот как-то все время этим занимался, а потом устал, бедняжка. Или ему создатели wayland следилку оторвали (см. начало третьего абзаца по ссылке)?

Мне надо было написать «DPI», а не «разрешением», но ладно. Следилку оторвали из соображений, насколько я знаю, безопасности.

А в иксах нельзя? Через Xrandr, например

Для отдельного окна?

Как он определит, поддерживает приложение масштабирование или нет?

Самый простой вариант — через правило в настройках.

sudopacman ★★★★★ ()
Ответ на: комментарий от anonymous

если не считать рандомных дерганий и одного угребищного бага который все портит

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

geek ★★★ ()
Ответ на: комментарий от sudopacman

разработка тулкита прекращена => поддержки wayland в тулките не будет, и чем тут нам помог wayland? тулкит сможет в hiDPI на wayland без поддержки тулкитом wayland? «Только вы с devzero предлагаете вариант, когда тулкит это сообщение посылает себе сам.» Ну да, тулкит при изменении координат окошечка смотрит не пересекло ли оно границы монитора, и если пересекло шлёт себе event перерисуйся в чём принципиальная проблема?

lberserq ()
Ответ на: комментарий от FiXer

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

anonymous ()
Ответ на: комментарий от lberserq

разработка тулкита прекращена => поддержки wayland в тулките не будет, и чем тут нам помог wayland? тулкит сможет в hiDPI на wayland без поддержки тулкитом wayland?

Есть XWayland. И приложения, работающие через XWayland можно апскейлить.

Ну да, тулкит при изменении координат окошечка смотрит не пересекло ли оно границы монитора, и если пересекло шлёт себе event перерисуйся в чём принципиальная проблема?

Научись читать.

sudopacman ★★★★★ ()
Ответ на: комментарий от sudopacman

Оконная система уже отвечает за работу с дисплеями, DPI и т. п. Зачем внедрять в тулкит ещё раз то, чем она занимается?

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

Нельзя заставить все тулкиты/приложения (как минимум потому, что разработка некоторых из них уже прекращена)

«Это OpenSource, поправь это сам. Или заплати тому, кто поправит, если сам не можешь,» — кричали они. «Сдохла твоя проприетарщина, а открыли бы исходники — нашлись бы те, кто доработал,» — кричали они. Весь этот форум такими лозунгами завален. Что, не работает эта фигня? Смешно и неудобно.

поддерживать HiDPI

HiDPI — это buzzword, с которым все носятся как с писаной торбой. Это модно нынче — «решать проблему HiDPI», и все ее решают, решают... Resolution independence? Не, не слышали... Вернее как, слышать-то слышали, но поняли как-то по-своему. И потом выясняется, что HiDPI это от 200, а все остальные, у которых 130-160, потерпят.

Только вы с devzero предлагаете вариант, когда тулкит это сообщение посылает себе сам.

Даже в мыслях не было предлагать такое. Где? Я изначально прикопался к твоему категоричному «в иксах нельзя сделать так, чтобы при перемещении между мониторами это масштабирование автоматически менялось». Можно. Я даже больше скажу: такое уже делали году этак в 2010, что-ли. Ссылку только найти не могу сейчас. Там энтузиаст патчил иксы и ГТК, и картинка была, где половина окна на одном мониторе, а вторая половина на другом, и линейные размеры одинаковые у этих половинок (т.е. все отрисовано в соответствии с DPI).

А в иксах нельзя? Через Xrandr, например

Для отдельного окна?

Зачем для отдельного окна? А если окно одной половиной на одном мониторе, а второй половиной — на другом, то ему какой DPI «установить»?

mamboo ()
Ответ на: комментарий от mamboo

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

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

«Это OpenSource, поправь это сам. Или заплати тому, кто поправит, если сам не можешь,» — кричали они. «Сдохла твоя проприетарщина, а открыли бы исходники — нашлись бы те, кто доработал,» — кричали они. Весь этот форум такими лозунгами завален. Что, не работает эта фигня? Смешно и неудобно.

Сказанное тобой вообще никак не опровергает мой аргумент.

HiDPI — это buzzword, с которым все носятся как с писаной торбой. Это модно нынче — «решать проблему HiDPI», и все ее решают, решают... Resolution independence? Не, не слышали... Вернее как, слышать-то слышали, но поняли как-то по-своему. И потом выясняется, что HiDPI это от 200, а все остальные, у которых 130-160, потерпят.

Во-первых, не 200, а 192. Во-вторых, никто не мешает добавить в композитор поддержку fractional scaling.

Даже в мыслях не было предлагать такое. Где? Я изначально прикопался к твоему категоричному «в иксах нельзя сделать так, чтобы при перемещении между мониторами это масштабирование автоматически менялось». Можно. Я даже больше скажу: такое уже делали году этак в 2010, что-ли. Ссылку только найти не могу сейчас. Там энтузиаст патчил иксы и ГТК, и картинка была, где половина окна на одном мониторе, а вторая половина на другом, и линейные размеры одинаковые у этих половинок (т.е. все отрисовано в соответствии с DPI).

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

Зачем для отдельного окна?

Во-первых, потому, что об этом изначально шла речь, во-вторых, это самый вменяемый способ.

А если окно одной половиной на одном мониторе, а второй половиной — на другом, то ему какой DPI «установить»?

Композитор не говорит окну о смене DPI. Он говорит о смене коэффициента масштабирования.

А логику поведения композитора можно придумать за несколько минут. Например: Если окно вдруг появилось прямо между двумя мониторами — присваивать наибольший коэффициент, на мониторе с меньшим DPI делать даунскейл. Если окно перетаскивается с одного монитора на другой — присваивать коэффициент в момент, когда его большая часть оказывается на одном из мониторов, меньшую часть сжимать или растягивать (в зависимости от ситуации).

sudopacman ★★★★★ ()
Ответ на: комментарий от anonymous

Они тебе в тапок нассали?

В глаза, угрёбищным тирингом и пропусками кадров. Ну и серпом по принципам UNIX-Way и KISS этот комбайн ещё знатно прошёлся.

В печь, однозначно.

EXL ★★★★★ ()
Ответ на: комментарий от ZenitharChampion

Раньше от этого избавляла настройка Unredirect Fullscreen Windows: когда ты включил VSync в настройках игры, то никакой другой VSync больше не применяется - Compiz на время игры отключается. Но эта настройка работает только в тех играх, в которых не работает Alt-Tab. На тех же, на которых работает Alt-Tab, это не работает.

В compton работает.

aidaho ★★★★★ ()
Ответ на: комментарий от aidaho

У меня на интеле работает с vsync=drm. А вот с xf86-video-intel я после какого-то его обновления намучался так, что плюнул и удалил его — настроить нормальный VSync было нереально.

spijet ()
Ответ на: комментарий от spijet

Какой из интелов? У меня на Kaby Lake тиринг с modesetting и vsync=drm просто уходит вверх экрана.

Интеловский DDX с его TearFree всё таки железобетонно работает.
Хоть сам драйвер в других отношениях и не подарок.
С включёнными семафорами весьма стабилен, пользую сейчас его.

aidaho ★★★★★ ()