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

Сам себе придумал каких-то линуксоидов с какими-то аргументами, сам же их опроверг. А по теме ничего не сказал.

У меня сейчас что с compton, что без него тиринга нет. Но это ничего не означает, потому что у кого-то он есть. В этом и есть проблема — она не возникает всегда. Поэтому её трудно решить.

Ога, ога. Трудная, не поддающаяся логике проблема. Но вейланд её решил. Магически. Помолимся!

Вместо описания просто заявляет: «УМВР, значит тиринга не существует».

А как найди-то это горе-птицу несчастья? Кто ее видел, эту Карну и Жлю?

Карн вернулся?

Карн вернулся?

Угу, смагу мычючи въ пламянѣ.

Ты сторонник вейланда?

А как найди-то это горе-птицу несчастья?

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

Магически

Не позорься.

Но вейланд её решил.

Там есть информация о том, когда кадр закончен, а в иксах этой инфы нет.

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

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

nvidia пойдет? Дальше-то что я должен сделать? Или на intel'е надо пробовать? Дальше ч0 там?

Там есть информация о том, когда кадр закончен, а в иксах этой инфы нет.

...и не может быть потому что это МАГИЯ.

Все контакты в профиле.

А теперь ясно, как увидеть тиринг: его нужно специально включить.

P.S. Вяленофилы, на секунду задумайтесь, почему никто до вас не озаботился проблемой тиринга? Вот в средневековье тоже была проблема: «Сколько чертей уместится на кончике пера?» Окружающие между ней и тирингом находят сходство необычайное.

Существенной разницы ... обнаружено не было

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

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

Это не есть правда, в X11 есть несколько различных способов формирования изображения окна. Класический - и в нем возможен тиринг, и со сменой битмап - там тиринга нету. В Wayland же есть только один способ формирования изображения и он ничем не отличается от второго подхода в X11. Мало того в первой модели X11 тоже довольно легко добавить транзакционность и убрать тиринг, просто никто этим не занимался всех устраивал второй подход ...

Это была ирония, дружок.

Поди вас разбери. Интересно, тут хоть кто-то всерьёз общается?

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

(зевает) знамо, знамо... WM_PAINT, InvalidateRect и всё такое. Тока мне казалось, мы тут о другом. Да и двойная буферизация в «очень давние» времена считалась делом слишком накладным.

наверное тиринга на вяленом нет потому что проприетарных дров нвидии нет, так?

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

Мой юный дружок

Со своим вяленым так будешь разговаривать.

На wayland'е только второе

Ты, как обычно, забыл аргументировать.

Мне что-то не кажется, что следить за расположением и разрешением мониторов — это задача тулкита.

и со сменой битмап - там тиринга нету.

XCopyArea на весь drawable считается? С ним всё равно бывает тиринг.

Дальше-то что я должен сделать?

Короче, вот. Йор эверадж икс аппликэйшн:

#include <X11/Xlib.h>
#include <stdio.h>
#include <unistd.h>

const int kWidth = 1024;
const int kHeight = 600;
const unsigned long kBackground = 0xa0a0f0;
const unsigned long kForeground = 0x000000;
const int kDelay = 15000;

int main(void) {
  Display *dpy = XOpenDisplay(NULL);
  Window root_wnd = DefaultRootWindow(dpy);
  Window wnd = XCreateSimpleWindow(dpy, root_wnd, 0, 0, kWidth, kHeight, 0, 0,
                                   kBackground);

  XMapWindow(dpy, wnd);
  XSync(dpy, False);

  GC gcf = XCreateGC(dpy, wnd, GCForeground,
                     &(XGCValues){.foreground = kForeground});
  GC gcb = XCreateGC(dpy, wnd, GCForeground,
                     &(XGCValues){.foreground = kBackground});

  int frame = 0;
  while (1) {
    for (int x = 10; x < kWidth - 10; x += 10) {
      for (int y = 0; y < kHeight; y++) {
        XDrawLine(dpy, wnd, gcb, x - 10, y, x, y);
        XDrawLine(dpy, wnd, gcf, x, y, x + 10, y);
      }
      printf("\rframe %d ready", ++frame);
      fflush(stdout);
      usleep(kDelay);
    }

    for (int x = kWidth - 10; x > 10; x -= 10) {
      for (int y = 0; y < kHeight; y++) {
        XDrawLine(dpy, wnd, gcb, x, y, x + 10, y);
        XDrawLine(dpy, wnd, gcf, x - 10, y, x, y);
      }
      printf("\rframe %d ready", ++frame);
      fflush(stdout);
      usleep(kDelay);
    }
  }

  return 0;
}

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

Существенной разницы в производительности игр, энергопотреблении и объёме занятой оперативной памяти обнаружено не было.

Ой да лаадна, я тут с сида перешёл на stable. Сижу такой катаю кс и не понимаю чего у меня пролаги жуткие рандомно летят, а тут в гноме расширение отключилось ну я по привычке alt+f2+r и тут мне в сеансе wyland перезапуск shell невозможен, я такой ооой да у меня всё под Xwyland, а я и не заметил, перезагрузил сеанс под Xorg и всё снова стало нормальным. Phoronix как всегда тестят по плану и желанию левой пятки, что раньше все их тесты были говно говном что сейчас всё оторвано от реальности чуть более чем полностью

Мне что-то не кажется, что следить за расположением и разрешением мониторов — это задача тулкита.

В смысле «не кажется»? А чья это задача?

Если у меня для сохранения визуального масштаба изображения на одном мониторе требуется физический размер шрифта 20 пикселей, а на другом 48, то кто мне их там такого размера нарисует, libastral?

...и не может быть потому что это МАГИЯ.

Wayland-клиент вынужден явно сказать «я закончил рисовать кадр», поэтому там эта информация есть. А X-клиент может рисовать что хочет и когда хочет. Остальным приходится только догадываться, когда можно взять и показать, что там клиент рисует.

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

И что ? Это проблемы ПО которое рисует а не сервера что оно не использует подходы по устранению тиринга. Или вы хотите сказать что если вот этот-же бинарник запустить внутри вайланд сесии (через XWayland) то оно магичиским образом будет работать без артифактов ?

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

Я говорю о переписанном КДЕ 4.

XCreateGC

XDrawLine

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

Wayland-клиент вынужден явно сказать «я закончил рисовать кадр», поэтому там эта информация есть. А X-клиент может рисовать что хочет и когда хочет.

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

А в вайланде теоретически может быть тоже самое, приложение может обнавлять содержимое окна частями (разными модулями / либами) и каждая часть будет рисовать свой кусок как отдельную транзакцию - и пользователь тоже будет видет кривое изаброжение вместо окна ...

Это проблемы ПО которое рисует а не сервера

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

Или вы хотите сказать что если вот этот-же бинарник запустить внутри вайланд сесии (через XWayland) то оно магичиским образом будет работать без артифактов ?

Wayland-клиент вынужден вызывать wl_surface_commit(). Поэтому композитор знает, что вот прямо сейчас можно брать кадр и он будет хорошим.

Wayland-клиент вынужден явно сказать «я закончил рисовать кадр», поэтому там эта информация есть. А X-клиент может рисовать что хочет и когда хочет. Остальным приходится только догадываться, когда можно взять и показать, что там клиент рисует.

Так и запишем: приложения на motif в вейланде не бликуют. Потому что под ним не запускаются.

Технические аргументы-то будут?

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

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

Wayland-клиент вынужден вызывать wl_surface_commit(). Поэтому композитор знает, что вот прямо сейчас можно брать кадр и он будет хорошим.

Что мне мешает как криворукому девелоперу натыкать wl_surface_commit() после каждого чиха ?

(2) изоляция приложений, благодаря которой приложения не имеют возможности тайком перехватить изображение на экране или нажатия на кнопки.

Он этим ВООБЩЕ НЕ ДОЛЖЕН ЗАНИМАТЬСЯ. И кстати. Раз уж про безопасность. А приведите-ка мне список актуальных CVE с рабочими эксплоитами для иксов. Вот когда и можно будет говорить о какой-то безопасности. А так - это бред. Это все равно, что маляра назначить главой службы безопасности.

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

Пожалуйста, не надо. X11 ничего не знает про Qt. Это Qt должен подстраиваться под X11. Но я что-то не нашёл в Xlib способа сказать серверу, что вот сейчас я всё закончил, вот это окно рисуй, а промежуточные варианты — не рисуй.

А в вайланде теоретически может быть тоже самое

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

Wayland-клиент вынужден вызывать wl_surface_commit(). Поэтому композитор знает, что вот прямо сейчас можно брать кадр и он будет хорошим.

А в иксах сказать композитору «бери хороший кадр» мешает... ну правильно, магия.

А в иксах сказать композитору «бери хороший кадр» мешает... ну правильно, магия.

Как это сказать композитору? Есть какой-то стандартный способ?

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

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

Как это сказать композитору? Есть какой-то стандартный способ?

Двойная буферизация.

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

Есть такая программка, https://github.com/zevv/bucklespring. Она есть в репозиториях. Поставь, запусти. Понажимай кнопочки. Слышишь звуки? Хорошо.

Теперь открой окно эмулятора терминала. Запусти там su, введи пароль рута. Слышал звуки, когда пароль вводил? Это потому что одно приложение просто решило прослушать все нажатия на клавиши. Круто, да?

Любое приложение может слушать ввод, может снимать картинки с экрана.

Двойная буферизация.

Ну конечно же нет указания конкретного вызова. На что я расчитывал? Это всё я сам должен придумать. А если не придумал, или если, скажем, XCopyArea не устраняет тиринг, это я просто неправильно нашёл, ага.

А чья это задача?

Композитора.

Если у меня для сохранения визуального масштаба изображения на одном мониторе требуется физический размер шрифта 20 пикселей, а на другом 48, то кто мне их там такого размера нарисует, libastral?

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

Ну... дык...

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

Пожалуйста, не надо. X11 ничего не знает про Qt. Это Qt должен подстраиваться под X11. Но я что-то не нашёл в Xlib способа сказать серверу, что вот сейчас я всё закончил, вот это окно рисуй, а промежуточные варианты — не рисуй.

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

У wayland двойная буферизация гвоздями прибита на стороне композитора, это не хорошо и не плохо - это просто по другому и все. В линуксе графический медленней чем в Windows не потомучто X11 - а потомучто он UserSpace и работает по IPC. А в Windows он встроен на уровне ядра OS.

Основным доводом в пользу Wayland был совсем не тиринг и кривые окна, а то что DWM отделен от композитора, и поэтому на сильно загруженых системах отзывчивость страдает (X11 получает сообщение из /dev/event -> Находт текущего обработчика (рамка окна) -> Шлет сообщение этому окну (DWM) -> DWM обрабатывает сообщение и понимает что нужно изменить позицию окна -> Шлет сообщение X11 -> Композитор обнавляет картинку)

В Wayland DWM и композитор это один процесс и они взаимодействуют прямым вызовом функций без никакого IPC - это явно быстрее тут спору нету. Но например меня и в X11 полностью устраивает общая отзывчивость системы ...

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

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

Ты там ниже про двойную буферизацию пишешь. И ведь есть давно уже dbelib. Который, правда, всё равно никто не использует, потому что он не работает. Вместо этого делают что? Копируют один буфер в другой. За маленькое, но конечное время. Что будет, если в это время происходит цикл обновления у композитора или просто рисование кадра в видеоадаптере? Тиринг.

Мой пример просто увеличивает вероятность.

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

Как бы пофигу. Ты на иксы молишься — вот тебе иксы.

Но сказать тулкиту, когда нужно менять размер, должен композитор.

На каком основании он должен? Вот API xrandr-а, вот события об изменении координат окна. Бери и реализуй любым способом, какие проблемы?

Я извиняюсь, любители вейланда совсем не умеют в логику?

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

Здрасти, приехали. Мы говорим про масштабирование GUI в окне, а не окна.

Есть какой-то стандартный способ?

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

Технические аргументы-то будут?

Нет.

Ты на иксы молишься — вот тебе иксы.

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

Вялендолюбцы тут втирают про магию и отказываются видеть за программным пакетом всего лишь программный пакет с неизбежно присущими ему недостатками. Но они не «молятся», а просто очень умные и незашоренные люди.

Ни мозгов, ни совести.

Там по тестам в 3D-графике у вяленда всё печально. На Unigine Valley это всё отчётливо видно. Потребление памяти и энергии на вяленде тоже выше.

Что мне мешает как криворукому девелоперу натыкать wl_surface_commit() после каждого чиха?

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

С иксами я намучался, пытаясь в приложении избавиться от тиринга. Даже ввёл такой костыль как usleep после ожидания ioctl(display.dri_fd, DRM_IOCTL_WAIT_VBLANK, &dwv);. Другие способы не работали.

Ни мозгов, ни совести.

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