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 ()
Ответ на: комментарий от EXL

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

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

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

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

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

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

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

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

Могу лишь сделать предположение, что дело в Mutter: он по умолчанию использует композитинг с помощью видеокарты.

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

Поверил. Естественно мне сложно самому.

Ну так интернет же. Кучу эетузиастов с тестами и обзорами всегда есть.

fornlr ★★★★★ ()
Ответ на: комментарий от 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 ()
Ответ на: комментарий от sudopacman

Иди почитай, зачем вообще не нужен Wayland и чем он хуже иксов. Если не понимаешь, то хотя бы не пиши чушь.

очевидная правка

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

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

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

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

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

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

На что-то более интеллектуальное ты, похоже, не способен.

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

А ты ожидал какой-то умный ответ на хамское «Иди почитай»? Какой наивный юноша.

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

Wayland уже готов, он используется в SailfishOS,

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

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

Иди почитай

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

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

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

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

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

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

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

Да ладно, проект, выпускающий раз в год минорный релиз с 1 багфиксом точно так же будут считать дохлым.

khrundel ()
Ответ на: комментарий от 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 ★★★★★ ()
Ответ на: комментарий от geek

удалятора декораций

чего?

глобального меню

зачем?

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

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

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

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

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

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

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

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

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

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

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

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

mamboo ()

Тем временем SUSE Linux Enterprise 15 первым из ынтерпрайзных дистров переходит на Wayland

http://www.opennet.ru/opennews/art.shtml?num=47467

Отлично. Остался Debian + CentOS/RHEL и иксы будут повержены.

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

и иксы будут повержены

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

anonymous ()
Ответ на: комментарий от 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 ★★★★★ ()
Ответ на: комментарий от EXL

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

Еще б адекватную замену перед этим дождаться.

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

vsync в compton не работает с modesetting, о чём можно почитать тикеты на гитхабе.

aidaho ★★★★★ ()
Ответ на: комментарий от 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 ★★★★★ ()
Ответ на: комментарий от aidaho

Мне не помог в XFCE — тирило как в аду. Пришлось ещё сверху Compton прикручивать. А в HLWM случался адок — в urxvt всё рассыпалось при прокрутке.

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

Хз, пользуюсь линуксом с 2005-го года и не знаю что такое тиринг.

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

Спасибо тебе, братан, ты тут единственный компетентный, ответил, что такое «тиринг». Рассинхрон. Именно поэтому в X'ах есть расширение SYNC. Гляди, всего лишь чуть-чуть модифицировать твой код:

#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <signal.h>
#include <time.h>
#include <xcb/xcb.h>
#include <xcb/sync.h>
#include <pthread.h>

const int kWidth = 1024;
const int kHeight = 600;
const unsigned long kBackground = 0xa0a0f0;
const unsigned long kForeground = 0x000000;
const unsigned long Tick = 1000000000 / 30;

pthread_mutex_t mutex = {PTHREAD_MUTEX_INITIALIZER};

typedef struct
{
	xcb_connection_t **con;
	xcb_drawable_t  *win;
	xcb_sync_fence_t *pfence;
} data;

void* func(void *p)
{
	data *pdt = (data*)p;

	int sig;
	sigset_t sigset;
	sigemptyset(&sigset);
	sigaddset(&sigset, SIGUSR1);
	sigaddset(&sigset, SIGUSR2);

	xcb_gcontext_t gc;

	int x = 10;
	int dir = 0;

	while (!sigwait(&sigset, &sig))
	{
		switch (sig)
		{
			case SIGUSR1:
			xcb_clear_area(*pdt->con, 1, *pdt->win, 0, 0, 1, 1);
			xcb_flush(*pdt->con);
			break;

			case SIGUSR2:
			pthread_mutex_lock(&mutex);

			gc = xcb_generate_id(*pdt->con);
			xcb_create_gc(*pdt->con, gc, *pdt->win, 0, NULL);
			if (x< kWidth && !dir)
			{
				for (int y = 0; y < kHeight; y++)
				{
					xcb_change_gc(*pdt->con, gc, XCB_GC_FOREGROUND, &kBackground);
					xcb_poly_line(*pdt->con, XCB_COORD_MODE_ORIGIN, *pdt->win,
						gc, 2, (xcb_point_t[]){{x - 10, y}, {x, y}});
					xcb_change_gc(*pdt->con, gc, XCB_GC_FOREGROUND, &kForeground);
					xcb_poly_line(*pdt->con, XCB_COORD_MODE_ORIGIN, *pdt->win,
						gc, 2, (xcb_point_t[]){{x, y}, {x + 10, y}});
				}
				x += 10;
				if (x >= kWidth)
				{
					x = kWidth;
					dir = 1;
				}
			}
			else if (x >= 0 && dir)
			{
				for (int y = 0; y < kHeight; y++)
				{
					xcb_change_gc(*pdt->con, gc, XCB_GC_FOREGROUND, &kBackground);
					xcb_poly_line(*pdt->con, XCB_COORD_MODE_ORIGIN, *pdt->win,
						gc, 2, (xcb_point_t[]){{x, y}, {x + 10, y}});
					xcb_change_gc(*pdt->con, gc, XCB_GC_FOREGROUND, &kForeground);
					xcb_poly_line(*pdt->con, XCB_COORD_MODE_ORIGIN, *pdt->win,
						gc, 2, (xcb_point_t[]){{x - 10, y}, {x, y}});
				}
				x -= 10;
				if (x <= 0)
				{
					x = 10;
					dir = 0;
				}
			}
			xcb_free_gc(*pdt->con, gc);

			xcb_sync_trigger_fence(*pdt->con, *pdt->pfence);
			xcb_flush(*pdt->con);

			pthread_mutex_unlock(&mutex);
			break;
		}
	}

	return NULL;
}

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

Продолжение:

int main (int argc, char* argv[])
{
	xcb_connection_t *connection;
	xcb_drawable_t  window;
	xcb_sync_fence_t fence;
	data dt = {&connection, &window, &fence};

	connection = xcb_connect(NULL, NULL);

	xcb_prefetch_extension_data(connection, &xcb_sync_id);
	xcb_get_extension_data(connection, &xcb_sync_id);
	xcb_sync_initialize(connection, XCB_SYNC_MAJOR_VERSION, XCB_SYNC_MINOR_VERSION);

	fence = xcb_generate_id(connection);
	xcb_sync_create_fence(connection, window, fence, 1);

	xcb_screen_t *screen = xcb_setup_roots_iterator(xcb_get_setup(connection)).data;

	window = xcb_generate_id(connection);
	xcb_create_window(connection, XCB_COPY_FROM_PARENT, window, screen->root,
		0, 0, kWidth, kHeight, 0, XCB_WINDOW_CLASS_INPUT_OUTPUT,
		screen->root_visual, XCB_CW_BACK_PIXEL | XCB_CW_EVENT_MASK,
		(uint32_t[]){kBackground, XCB_EVENT_MASK_EXPOSURE});

	pthread_attr_t attr;
	pthread_attr_init(&attr);
	pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED);

	sigset_t sigset;
	sigemptyset(&sigset);
	sigaddset(&sigset, SIGUSR1);
	sigaddset(&sigset, SIGUSR2);
	pthread_sigmask(SIG_BLOCK, &sigset, NULL);

	timer_t timer;
	struct sigevent se = {.sigev_notify = SIGEV_SIGNAL, .sigev_signo = SIGUSR1};
	struct itimerspec its = {.it_value.tv_nsec = 1, .it_interval.tv_nsec = Tick};
	timer_create(CLOCK_REALTIME, &se, &timer);
	timer_settime(timer, 0, &its, NULL);

	pthread_t thread;
	pthread_create(&thread, &attr, func, &dt);

	xcb_map_window(connection, window);
	xcb_flush(connection);

	int frame = 0;
	xcb_generic_event_t *event;

	while ((event = xcb_wait_for_event(connection)))
	{
		switch (event->response_type & ~0x80)
		{
			case XCB_EXPOSE:
			pthread_mutex_lock(&mutex);

			xcb_sync_reset_fence(connection, fence);
			xcb_flush(connection);

			pthread_kill(thread, SIGUSR2);
			pthread_mutex_unlock(&mutex);

			xcb_sync_await_fence(connection, 1, &fence);

			printf("\rframe %d ready", ++frame);
			fflush(stdout);
			break;
		}
		free(event);
	}

	return 0;
}
То, к чему ты имел претензии. С моей стороны, хотелось бы настоящих путей, а не этих полукостылей.

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

Спасибо.

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

P.S. А еще более нужна нормальная документация на X'ы. Продукт документирован отвратительно.

P.P.S. Еще раз тебе спасибо: ты ясно мыслишь, не стесняйся высказываться.

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.