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

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

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

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

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

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

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

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

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

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

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

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

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

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

У тебя на аватарке путана по имени Путинка?

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

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

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

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

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

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

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

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

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

Да.

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

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

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

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

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

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

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

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

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

Ответ на сообщение www.linux.org.ru/forum/talks/13780081

Таня поправляется в общую палату перевезли. Сам то я не в МСК живу. А так да. Переживаю...

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

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

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

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

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

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

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

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

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

Поддерживаю. Хорошо сказано.

Иди почитай

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

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

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

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

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

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

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

аргументов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

чего?

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

зачем?

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

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

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

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

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

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

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

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

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

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

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

чего?

того. см. unity

зачем?

купи ноутбук

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В compton работает.

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

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

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

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

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

Спасибо тебе, братан, ты тут единственный компетентный, ответил, что такое «тиринг». Рассинхрон. Именно поэтому в 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;
}

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

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;
}

Круто. Спасибо.

Спасибо.

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

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

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