Программы на голом протоколе X11 или Motif (xclock, acme, nedit) медленно меняют размер окна и содержимое дёргается. С программами на Qt/GTK такого не наблюдается. Кто нибудь знает, чем это вызвано? X.Org сломали?

Медленно — это как? Если медленное означает «видно глазом, как приложение делает relayout несколько раз подряд», то это всегда так было. Собственной двойной буферизации приложения на Motif не имеют, а встроенную в XOrg выпилили лет 10 назад, если не 15.

Впрочем, у nedit этого даже не видно, т.к. там и интерфейса-то нет: сверху меню и снизу текст.

Если же, что-то иное, то нет, так быть не должно.

openSUSE, KDE

X11 работает через Wayland?

Оффтоп

openSUSE

Удивлён, что кроме меня, Зенитара и еще пары человек, ей кто-то пользуется из местных.

Медленно — это как?

Как будто 15 FPS вместо 60.

а встроенную в XOrg выпилили лет 10 назад, если не 15.

Зачем?

X11 работает через Wayland?

Нет, через X.Org. Wayland не запущен.

Дистровотч говорит об обратном.

Зачем?

«Потому что ненужно, приложения должны делать буферизацию сами на уровне тулкитов.»

У нас вообще 80% графического стека пишется без попытки задавать такой вопрос.

«Потому что ненужно, приложения должны делать буферизацию сами на уровне тулкитов.»

Они предлагают использовать растровый буфер вместо векторных команд и убить скорость X11 программ по сети? В Haiku изначально сделали двойную буферизацию на уровне сервера и графика по сети работает.

Кому не нужна серверная графика пусть на Wayland переходят, зачем ломать X.Org.

да, это известная проблема. голые иксы это говнище

Я помню винду конца 90-х начала 2000-х, всегда масштабирование было тяжелой операцией, я отключал отображение окон в момент ресайза, чтоб в процессе изменения размеров отображались только рамки окна.

во времена xp ресайз летал

Они предлагают использовать растровый буфер вместо векторных команд и убить скорость X11 программ по сети?

Зависит от тулкита.

GTK2 заводит буфер на стороне сервера и рисует векторными операциями туда. А потом говорит: «а скопируй-ка мне вот этот прямоугольник из буфера в окно».

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

GTK2 вменяемо работает по сети. Хотя отдельные приложения могут тупить, которые выполняют отрисовку своих кустомных виджетов на клиенте.

В Haiku изначально сделали двойную буферизацию на уровне сервера и графика по сети работает.

XOrg не дураки проектировали, там была предусмотрена фича «двойная буферизация окна», и она работала как хинт: если сервер её не поддерживает, то она и не работает. Или если у сервера слишком мало памяти, например.

То есть приложение просто рисует в окно как обычно, а потом говорит, что «теперь можно обновить картинку».

Потом её просто отключили, а код убрали. В спеках она до сих пор есть.

Они предлагают использовать растровый буфер вместо векторных команд и убить скорость X11 программ по сети? В Haiku изначально сделали двойную буферизацию на уровне сервера и графика по сети работает.

И чем двойная буферизация в X.org поможет при изменении размеров окна?

У тебя, скорее всего, XRender отвалился. Или какой-то тормозной композитор запущен, который вместо того, чтобы помогать, только портит.

И чем двойная буферизация в X.org поможет при изменении размеров окна?

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

GTK2 заводит буфер на стороне сервера и рисует векторными операциями туда.

В GTK3 всё сломали или этот механизм ещё есть?

Не смотрел.

Последний раз я заглядывал в сорцы gtk3, когда минорная версия еще состояла из одной цифры. Что там сейчас, не знаю.

У тебя, скорее всего, XRender отвалился.

Чем он поможет? Изменение размера окна тормозит даже на минимальном примере X11. Видно слайд-шоу с рамкой окна.

Или какой-то тормозной композитор запущен, который вместо того, чтобы помогать, только портит.

Как это проверить? Какой композитор не тормозной?

Чем он поможет?

Так он есть или его нет?

Какой композитор не тормозной?

Самый быстрый вариант — отсутствие композитора.

Двойная буферизация — дополнительная нагрузка и на GPU, и на CPU. Как именно эта дополнительная нагрузка приведёт к ускорению некой CPU-задачи в десять раз? Разъясни механизм, пожалуйста.

Так он есть или его нет?

number of extensions:    28
    BIG-REQUESTS  (opcode: 133)
    Composite  (opcode: 142)
    DAMAGE  (opcode: 143, base event: 91, base error: 152)
    DOUBLE-BUFFER  (opcode: 145, base error: 153)
    DPMS  (opcode: 147)
    DRI2  (opcode: 155, base event: 119)
    DRI3  (opcode: 149)
    GLX  (opcode: 152, base event: 95, base error: 158)
    Generic Event Extension  (opcode: 128)
    MIT-SCREEN-SAVER  (opcode: 144, base event: 92)
    MIT-SHM  (opcode: 130, base event: 65, base error: 128)
    Present  (opcode: 148)
    RANDR  (opcode: 140, base event: 89, base error: 147)
    RECORD  (opcode: 146, base error: 154)
    RENDER  (opcode: 139, base error: 142)
    SECURITY  (opcode: 137, base event: 86, base error: 138)
    SHAPE  (opcode: 129, base event: 64)
    SYNC  (opcode: 134, base event: 83, base error: 134)
    X-Resource  (opcode: 150)
    XC-MISC  (opcode: 136)
    XFIXES  (opcode: 138, base event: 87, base error: 140)
    XFree86-DGA  (opcode: 154, base event: 112, base error: 179)
    XFree86-VidModeExtension  (opcode: 153, base error: 172)
    XINERAMA  (opcode: 141)
    XInputExtension  (opcode: 131, base event: 66, base error: 129)
    XKEYBOARD  (opcode: 135, base event: 85, base error: 137)
    XTEST  (opcode: 132)
    XVideo  (opcode: 151, base event: 93, base error: 155)

Самый быстрый вариант — отсутствие композитора.

Мигать стало меньше, но тормоза не ушли. Загрузка CPU не большая. Dolphin масштабируется без тормозов.

Двойная буферизация — дополнительная нагрузка и на GPU, и на CPU. Как именно эта дополнительная нагрузка приведёт к ускорению некой CPU-задачи в десять раз? Разъясни механизм, пожалуйста.

Она не уменьшает время выполнения задачи, но уменьшает количество перерисовок экрана, которые заметит пользователь.

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

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

Грубо говоря, если ты тянешь за угол окна мышкой, с буферизацией ты увидишь 10 разных кадров, а без неё — 50, но из них 40 будут недорисованными. Это увеличивает воспринимаемое мерцание экрана, т.к. интерфейс в каждой случайной точке окна то есть, то нет.

Кстати, может у ТС-а как раз композитный менеджер тупит.

Грубо говоря, если ты тянешь за угол окна мышкой, с буферизацией ты увидишь 10 разных кадров

Почему должно быть 10 кадров, если железо нормальное и нет тяжёлой графики? Обновление по таймеру вызывается?

Кстати, проверил под Windows 7.

Не буферизируют вывод:

• Notepad++.
• XnView.
• Total Commander, SynWrite и наверное прочие приложения на Delphi.

Буферизируют:

• LibreOffice. Но пока не выполнил отрисовку нового интерфейса, закрашивает поля черным, а не светлым, из-за чего сильное мерцание. И дико, невероятно тупит.
• Firefox. Но пока не выполнил отрисовку нового интерфейса, закрашивает поля черным, а не светлым, из-за чего сильное мерцание.
• qBittorrent.
• HxD Hex Editor.
• IrfanView.
• Проводник. И отрисовывается очень быстро.
• 7-Zip. Рисуется просто реактивно.

Всё чисто визуально, могут быть неточности.

с буферизацией ты увидишь 10 разных кадров, а без неё — 50, но из них 40 будут недорисованными.

А, вот ты о чём.

Мигать стало меньше, но тормоза не ушли.

Мигание в иксах неизбежно. Они так устроены.

А вот тормоза простого объяснения не имеют. Слишком много вариантов.

встроенную в XOrg выпилили лет 10 назад, если не 15.

А можешь подробнее рассказать?

Как называлось это расширение?

А приложение по какому принципу перерисовывается при масштабировании? У меня похожая штука была когда мотифный бэк свинга (Ява) в первый раз запускал на 4к на голимом Арме - вообщем окно можно:

• перерисовывать при каждом изменении размера (по сути при перемещении на каждый пиксель - т.е. при обычном движении мыши это 100-200 раз в секунду)
• через N изменений (не через каждый пиксель, а, например не чаще 60 раз в секунду ибо один фиг 60гц монитор особо больше и не покажет, либо раз 10 ибо «достаточно»
• после завершения масштабирования (привет рамочки отдельные от окна)

Фишка в том, что если у тебя сложный гуй (всякие там хитрые лайоты и тп) то он будет «дергаться» при частой перерисовке, а если в потоке гуя ещё что-то бегает, то совсем пичаль

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

Фишка в том, что если у тебя сложный гуй (всякие там хитрые лайоты и тп) то он будет «дергаться» при частой перерисовке, а если в потоке гуя ещё что-то бегает, то совсем пичаль

Даже пустое окно тормозит, а Dolphin с хитрыми лайоутами не тормозит.

Dolphin

Хм. А ты уверен, что у тебя иксы, а не Wayland-сессия, в которой иксовые приложения запускаются через Xwayland? На чём-то простом типа openbox проверял?

Даже пустое окно тормозит, а Dolphin с хитрыми лайоутами не тормозит.

Значит в окне - баг (с)

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

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

никакого мерцания не наблюдаю

Это что-то доказывает?

Ну мне тут доказывают что это встроенный порок X11. Я его вижу только в Xorg и только на новомодных драйверах без акселерации.

Намекаешь на то, что это особенность X.Org, а X11 на самом деле изначально транзакционный?

Я скорее хочу сказать, что это следствие натягивания совы на глобус начатые еще командой XFree86 и продолженные Xorg, когда на то, как все работает внутри всем плевать и надо быстро сбоку приляпать как-то работающие костыли. Плюс еще массовая андроизация десктопа, когда по факту единственным ускоренным векторным отрисовщиком стал OpenGL и вместо того чтобы сделать через это нормальную оконную систему все кинулись работать помимо оконной системы. И количество таких решений нарастает как снежный ком. Соответственно постоянно разваливается все больше и больше еще недавно работавших железно вещей. Допустим вейланд «решит» часть этих проблем, но ничто не стоит на месте и тенденция продолжится. Какое же все-таки решение может быть более постоянным, чем костыли типа wayland’a? Ведь вряд ли сейчас кто-то способен сейчас родить что-то выше уровня «десктопа» встройки. Перенос графики Android?

Эти рассуждения я уже где-то видел. За многие годы их в интернете накопилось больше, чем хотелось бы. Но это всё какие-то сворачивания в сторону. Меня больше интересует, является ли немедленная отрисовка, следствием которой является мерцание, свойством X11 или нет?

Протокол синхронный, но отрисовку определяет только драйвер. Но отрисовка встает в очередь, то есть менять порядок произвольно не получится. Но у меня был опыт разносить отрисовку по приоритетам, то есть делать обновление зон окон асинхронно не получится, но внутри окон вполне. Главное чтобы сервер занимался отрисовкой нормально, а не что-то сбоку. Это вполне делается, но никому в открытых реализациях это не надо, их и так все устраивает. Это нужно в основном только тем, кто графику через протокол X11 гоняет по сети. Локально, если графика не тормозит, должно все хорошо быть. И да, с двойной/тройной буферизацией и vsync тоже все хорошо делается на уровне драйвера.

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

Wine программы тоже тормозят при изменении размеров окна.

Меня больше интересует, является ли немедленная отрисовка, следствием которой является мерцание, свойством X11 или нет?

Ты же прекрасно знаешь, что да, зачем спрашиваешь?

И, да, это совсем не проблема. Во всех графических подсистемах так. Там, где это нужно, используется рисование в pixmap, потом содержимое сбрасывается в окно (в X'ах, возможно, через xcb_present_pixmap).

Для большинства приложений это просто не нужно и пустой расход ресурсов. Теребение этого вопроса напоминает незабвенное «Сколько чертей помещается на кончике иглы»?

Протокол синхронный, но отрисовку определяет только драйвер.

И как драйвер определяет, что вот до этой команды можно их копить, а вот после этой обязательно отрисовать? Магия?

Ты же прекрасно знаешь, что да, зачем спрашиваешь?

Пытаюсь выстроить логическую цепочку, чтобы убедить собеседника в том, что ответ — «да».

Во всех графических подсистемах так.

Ну не обязательно же.

Пытаюсь выстроить логическую цепочку, чтобы убедить собеседника в том, что ответ — «да».

Почему? Тут выше про двойную буферизацию на уровне сервера писали. Можно как в Haiku сделать.

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

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

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

Тот же X.Org с самого начала форка делался тяп-ляп, и дело вовсе не в архитектуре X11.

Ну не обязательно же.

Что не обязательно? Не обязательно писать нормальный код и делать архитектуру, чтобы рисовать? Вот свидетели вейланда на десктопе как раз так думают. Будто те люди, которые накодили стек X.Org + gtk2 заплатка на заплатке, сейчас соберутся и накодят Wayland + gtk4, и всё будет хорошо.

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

Нельзя как-нибудь отследить окончание обработки сообщения expose? По какому принципу оно вообще генерируется в X.Org? В Windows и Haiku аналогичное сообщение генерируется 1 раз и следующее сообщение будет сгенерировано только после того как текущее сообщение было обработано. Если запросить перерисовку когда есть необработанное сообщение expose, то запрос будет добавлен к dirty региону и нового сообщения не будет.

Почему? Тут выше про двойную буферизацию на уровне сервера писали.

Видимо, без примера никак. Допустим, некое приложение рисует своё состояние отдельными точками. Сначала стирает всё содержимое, потом отрисовывает по точке за команду. Каждая команда рисует точку в буфер, потом буфер презентуется. Сервер никак не может знать, закончило приложение рисовать или нет, поэтому вынужден копировать задний буфер в передний каждый раз. И как двойная буферизация тут поможет избежать мерцания при перерисовке?

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

Можно как в Haiku сделать.

Это уже не будет X11, и старые программы отвалятся.

Во всех графических подсистемах так.

Ну не обязательно же.

Что не обязательно?

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

Это уже не будет X11, и старые программы отвалятся.

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

Э-э-м… Вперёд? Что тебя останавливает?

Это уже не будет X11, и старые программы отвалятся.

Слушайте, мужики, ну это не смешно уже давно. Я этот цирк слышу который год. «Вот это сделать -> это уже будет не X11, и старые программы отвалятся». Логику включите: обратная совместимость для чего существует?

Напоминает те самые пресловутые глобальные хоткеи, которые не работают из-за идиотских тулкитов. Хотя ничего не мешает плоскую модель захвата заменить на иерархическую даже без переделки тулкитов. Тоже: «ой, приложения отвалятся». Да нет, если делать архитектуру придя в сознание, ничего не отвалится.

Э-э-м… Вперёд? Что тебя останавливает?

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

Я смотрю на интерфейс 7-Zip под виндой и не понимаю: почему 7-Zip успевает при изменении размеров окна перерисовываться так быстро, что глазом невозможно заметить апдейт, а всякое остальное ховно типа LibreOffice – не только не успевает уложиться в один кадр, но конкретно тупит?

В X11 у старых программ UI «дрожит», потому что они не знали, как засинхронизироваться с сервером. Потом идёт некоторое количество программ, которые рисуются через XRender, и рисуются правильно. Потом идут современные монстры, которые снова «дрожжат», но не потому, что не знают правильного API, а потому что уже не могут, не способны. Та же самая тенденция, независимо от графической системы под капотом.

А смысл на себя одеяло натягивать? Ты, зенитар и ещё пара человек, говоришь? С чего ты взял-то?

Какой ОС вы пользуетесь на основном ПК?