Медленно масштабируются X11 окна

Я часто пользуюсь drag&drop. В Wayland его нет?

Почитал спеку: вроде есть. Поэтому что собеседник имел в виду, осталось загадкой. И в одной системе DnD, и в другой DnD.

В Wayland его нет

Оно есть. См.XDND и как оно реализуется - это феерически извращённый секс.

Транзакционность не отменяет синхронности. В X11 на уровне драйвера ничто не мешает рисовать транзакционно - но это не уберет синхронность. Есть возможность немного обмануть систему за счет API 2D-акселерации, если его впилить обратно, но современные драйверописатели сделали свой выбор.

Транзакционность не отменяет синхронности. В X11 на уровне драйвера ничто не мешает рисовать транзакционно - но это не уберет синхронность.

Ты точно понимаешь, о чём речь идёт? Всё, что между командами «начать рисовать» и «закончить рисовать», не будет видно другим приложениям по частям. Либо ничего, либо всё сразу.

Что значит в твоём понимании «рисовать транзакционно» на уровне драйвера? Отдельные команды выполнять атомарно?

Ну, как обычно своя очередь команд, которая атомарно выполняется. Если пришла отмена, дропаем буфер. А как еще?

Как определить, где границы атомарно выполняемого блока команд?

Не очень понимаю вопрос. Прямоугольная область?

Вот есть поток команд. К примеру,

Line(0, 0, 10, 0)  
Line(10, 0, 10, 10)  
Line(10, 10, 10, 0)  
Line(10, 0, 0, 0)  

Как определить, какие команды принадлежат одной группе, а какие — к следующей?

Ну в моем случае обычно команды рисования перемежались с командами выбора области (клиппинга) и они служили точками синхронизации. То есть в разные clipping region’ы можно было рисовать в любой последовательности или одновременно. На железке без 2D-акселерации без реализации рендера через GL все плохо как раз из-за отсутствия точек привязки к кадру. По сути у тебя есть фрейм и все участники процесса его отрисовывают, как закончили - флипают в нужный момент. Если кто-то не успел отрисоваться за указанное время, тот кривое поделие и не нарисует ничего до следующего флипа. Возможно даже никогда. Но на такие ограничения шли осознанно, хотя можно было использовать маски и промежуточные буфферы, но тогда страдала отзывчивость и плавность. Тройная буферизация частично спасала, но до коле.

Как выделить в сплошном потоке команд отрисовки регионы - можно просто использовать гриды и dirty rectangles, которые умеет любая уважающая себя 2D-акселерация. Дальше как обычно.

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

А если программа использует клиппинг несколько раз для отрисовки одного кадра?

Сдаётся мне, что у вас был самописный сервер, который заточили под конкретные программы-клиенты. И на основе этого опыта ты теперь пытаешься приписать свойства конкретной реализации протоколу X11 вообще.

все равно рисование идет в ограниченной области

Нет, я просто описываю оптимизации пайплайна, которые были сделаны под конкретное железо. Протокол обычный, клиенты обычные (но без тяжелых растров).

Отлично. Вы замаскировали проблему так, что она не проявляется на том ограниченном наборе приложений, что вы используете. И ты этот опыт обобщил до всех возможных приложений. Классический пример УМВР ЧЯДНТ.

все равно рисование идет в ограниченной области

Речь про предотвращение мерцания и тиринга, а не про оконные регионы. Например есть поток графических команд:

ClipToRect(100, 100, 200, 200);
FillRect(0, 0, 1000, 1000, 0xff0000);
ClipToRect(120, 120, 220, 220);
FillRect(0, 0, 1000, 1000, 0x00ff00);
ClipToRect(140, 140, 240, 240);
FillRect(0, 0, 1000, 1000, 0x0000ff);
Flush();
ClipToRect(100, 100, 200, 200);
FillRect(0, 0, 1000, 1000, 0xff0000);
ClipToRect(120, 120, 220, 220);
FillRect(0, 0, 1000, 1000, 0x00ff00);
ClipToRect(140, 140, 240, 240);
FillRect(0, 0, 1000, 1000, 0x0000ff);
Flush();
ClipToRect(100, 100, 200, 200);
FillRect(0, 0, 1000, 1000, 0xff0000);
ClipToRect(120, 120, 220, 220);
FillRect(0, 0, 1000, 1000, 0x00ff00);
ClipToRect(140, 140, 240, 240);
FillRect(0, 0, 1000, 1000, 0x0000ff);
Flush();

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

Ну блин ну как ты отрисуешь гуй у приложения, которое не успевает отрисовать его за фрейм в силу того, что вынуждено все само нарисовать на растре и его еще 3 раза скопировать? Это как бы не проблема протокола. Если бы 2D-акселерация была на месте - все бы было нормально. А так… Есть наработки по реализации 2D-акселерации через GL и всякие аппаратные композиторы армовых железок. Но это опять же поможет с композитингом и флиппингом, тайлингом и прямоугольниками, но никак не с отрисовкой растра вручную. Если растр рисуется атомарно через какой-нить GL, то поможет tripple-buffering, если его рисует cairo за кучу вызовов, все, что можно сделать - рисовать пустое окно до тех пор пока аппа не сподобится отрисоваться. И тут начнутся вопли «какого хера я таскаю окно по экрану, а оно пустое и появляется только через секунду после остановки». Ну или рисовать недорисованное и наслаждаться мусором на экране.

А если мы вместо Flush() используем ClipToRect() и маркируем «грязные» области для отрисовки, эффект будет тот же. В драйвере у нес есть понятие фрейма и мы рисуем в его пределах (асинхронно), то есть когда попало отрисовка не происходит. Да, есть некоторые нюансы, то есть могут быть видны неотрисованные области, если что-то пошло не так с приложением, но тут лучше так, чем никак, так как главное - отзывчивость интерфейса, для чего фреймы должны ходить четко и вовремя.

А если мы вместо Flush() используем ClipToRect() и маркируем «грязные» области для отрисовки, эффект будет тот же.

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

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

Ресайз летал на хардверных «оконных ускорителях». Матроксы, Ati Mach, вот это всё.

Это всё из угрёбищной реализации масштабирования в макоси повелось.

А что за проблемы с макосью? Вот у меня рядом макбук, на нём масштабирование до More Space, мыла не вижу в упор. Почему в линуксах не так?

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

Ну так сделай же. Вот сейчас хромиум по контекстному меню делает grab клавиатуры и мыши потому, что так сказано в x11-мануалах. Вот рядом GUI виртуалки делает то же самое потому, что ему нужно пробросить хоткеи внутрь неё. Иксы, естественно, не могут (да и не пытаются) отличить их друг от друга и, например, глобально отлавливаемая клавиша «play/pause» не работает ни в том, ни в другом случае.

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

https://9to5mac.com/2016/12/02/15-inch-macbook-pro-screen-resolution-blurry/

Ну так сделай же.

Я последний программист на глобусе? Все остальные только лапками на ЛОРе могут? Я пишу движок форума для ZeroNet, и целую кучу утилит для линя.

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

Иксы. Иксам достаточно знать приоритет захвата. Всё.

и через сколько лет это будет в апстриме?

Никогда. Они 10 лет не могут принять патч для работы Alt+Shift. Это осознанная политика, а не чья-то недоработка. Вы должны ненавидеть существующее и молиться на будущие релизы новых технологий, которые вот-вот и всё исправят. Надо только чуток потерпеть. Еще 20 лет.

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

В BeOS/Haiku изначально такой проблемы не было, т.к. вместо захвата используется дублирование сообщений ввода. Можно попросить систему присылать сообщения ввода вне зависимости от фокуса.

Но ты не можешь взять и сделать то же самое в линуксе без изменения уймы приложений.

И да, в kde+wayland баг RESOLVED FIXED. Решение для иксов, которое не будет работать прямо сейчас, не нужно практически никому.

Иксам достаточно знать приоритет захвата

Но этот приоритет будет говорить приложение! И собственно этому приложению нужно будет объяснить, что у иксов появилось новое API для этого приоритета. То есть патч к каждому тулкиту + к бестулкитному, но популярному софту.

Но этот приоритет будет говорить приложение! И собственно этому приложению нужно будет объяснить, что у иксов появилось новое API для этого приоритета. То есть патч к каждому тулкиту + к бестулкитному, но популярному софту.

https://stackoverflow.com/questions/8104904/identify-program-that-connects-to-a-unix-domain-socket

Но ты не можешь взять и сделать то же самое в линуксе без изменения уймы приложений.

А к какому-нибудь libinput напрямую обратиться нельзя?

И да, в kde+wayland баг RESOLVED FIXED

Выпиливанием global hotkey как концепции вообще?

И да, это не тот баг. Потому что:

Решение для иксов, которое не будет работать прямо сейчас, не нужно практически никому.

Решение для иксов, которое позволяет делать так, чтобы меню не блокировало клавиатуру, существует столько же, сколько сами иксы. Баг в gtk и qt. Они 20+ не могли его починить, а виноваты иксы.

Может хватит лицемерить?

Firefox под какими-то другими иксами работает? Или Opera? Или Fox Toolkit?

Можно, но

• обычно, нужно добавить input-группу потому, что у юзера по дефолту нет доступа к устройствам ввода
• нужно объяснить всему желающему хоткеи софту что работать нужно с libinput, а не с x11.

Ты хочешь сказать, что ментейнеры каждого дистрибутива — социопаты и не хотят включить патчи для gtk+ и qt для починки глобальных хоткеев только потому, что они ненавидят юзеров?

https://stackoverflow.com/questions/8104904/identify-program-that-connects-to-a-unix-domain-socket

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

Нет, я хочу сказать, что авторы gtk и qt — идиоты.

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

Отлично, теперь осталось в дистрибутивы вшить маппинг между одобренным софтом и приоритетом граббинга.

Это называется Role Based Access Control.

Ну и придумать вменяемый дефолт на случай если кто-то реально пользуется иксами через сеть.

Всё удалённое считать недоверенным, пока пользователь не потребовал иного. (Через polkit.)

Я нажимаю Alt + F, чтобы открыть меню «Файл» в Firefox.

Потом нажимаю Win + F2, чтобы переключить рабочий стол.

Всё работает. Сеанс X11.

Вопрос о том, кто ненавидит юзеров, оставим открытым для размышлений.

Нет, я хочу сказать, что авторы gtk и qt — идиоты.

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

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

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

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

В винде никогда не парились с вопросом активации меню. Если есть меню, то должно быть top-level окно, которое за него отвечает.

Зачем-то в тулкитах под X11 решили, что у них будет свой путь, и меню должно работать вопреки логике передачи фокуса. Поэтому нужен был этот костыль.

Убунта пыталась много чего патчить

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

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

Так и было.

Как минимум, Canonical форкнула Nautilus в попытке спастись от массового выпиливания фич Гномом. Но ничего не вышло.

Но ничего не вышло.

Почему? Надо бы уже послать разработчиков Гнома куда подальше. Видимо Canonical не умеет вести срачи, надо их на стажировку на ЛОР пригласить :)