Рисует наверное сам wayland. А как уж это у него реализовано - другой вопрос, gtk и qt тут не виноваты. :)

Тогда как устроен процесс рисования? Вот должна быть кнопка по координатам 500:500, как тулкит присобачит рамку кнопки для отправки тому же вяленому? Я это представляю, как будто тулкит создает картинку с разрешением окна, рисует кнопку, отправляет картинку вяленому вяленому. Пользователь навел курсор на кнопку? меняем цвет рамки, отправляем вяленому. Или отправляем только измененные части? Как эта магия реализована вообще?

http://blog.mecheye.net/2012/06/the-linux-graphics-stack/

Новый anonimous чтоль завелся?

http://wayland.freedesktop.org/architecture.html

никакой магии

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

Или отправляем только измененные части?

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

Занимательная информация, а как устроен этот бэкбуфер? Как тулкит с ним взаимодействует? Не картинкой случаем генерирует? У тулкитов есть различные возможности вроде округлений кнопки, тени и т.п. - что с производительностью? На дно тянет сложность просчитывания тени или частота отправки изменений в буфер (аля анимация при наведении)? Как gtk отрисовывает шрифты через pango? Посыпались вопросы)

а как устроен этот бэкбуфер?

массив пикселей.

Как тулкит с ним взаимодействует?

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

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

на современном компьютере на дно не тянет ничего. на старом эффекты целесообразно отключить.

Как gtk отрисовывает шрифты через pango?

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

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

Т.е. gtk не сам управляет растановкой пикселов, а использует примитивы от cairo? Или рулит сам, но буфер гонит через cairo?
Как происходит генерация тени? Генерируются 8 буферов (png картинок) для последующего наложения: 4 на углы и 4 относительно стороны. Последние выглядят как узкие полоски. Если это не так, то данная реализация была бы производительней?

Т.е. gtk не сам управляет растановкой пикселов, а использует примитивы от cairo?

да.

Как происходит генерация тени?

понятия не имею.

8 буферов (png картинок)

растровые буферы - уж никак не PNG картинки. если уж связывать их с форматом изображений, это будет BMP без RLE-сжатия и заголовков.

Новый anonimous чтоль завелся?

Я так понимаю, это старый, вновь реинкарнировавший после забана nuboquest

растровые буферы - уж никак не PNG картинки. если уж связывать их с форматом изображений, это будет BMP без RLE-сжатия и заголовков.

PNG привел как поддержку прозрачности, но не суть. Ковертировал картинку 1920*1080 в BMP, получил 5.9МБ. 1920*1080=2073600 пикселов. 5900000/2073600=~2.8Б на пиксель. Сильно ли уменьшится в реалиях передачи буфера?

Сильно ли уменьшится в реалиях передачи буфера?

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

nuboquest разве не anonimous? :}

Шизофреник, прими таблетки!

Самое смешное, что он еще до забана вылез. Как чуял. Говорят, у шизофреников вообще чутье обостренное.

nuboquest разве не anonimous? :}

Ну вот я и говорю, это не новый anonimous, а снова старый.

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

Кажется так это работает

Как происходит встраивание иконок в буфер (картинки на форме)? Подгружается картинка в минибуфер, налаживается на буфер и вуаля? Почему тогда qt городит свой QSS, а gtk через cairo всё делает? Не проще «точку» на скроллбаре картинкой сделать? Как это в каком-нибудь FLTK или другом легковесном тулките реализовано?

Догадки не верны, вон уже сколько не по теме написали.

Подгружается картинка в минибуфер, налаживается на буфер и вуаля?

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

Почему тогда qt городит свой QSS, а gtk через cairo всё делает? Не проще «точку» на скроллбаре картинкой сделать?

не знаю, что такое QSS, отвечу про GTK+. во-первых, для экономии размера. во-вторых, для уменьшения числа дисковых операций. в-третьих, чтобы иметь возможность свободно масштабировать виджеты - с растровыми картинками так не сделать.

Как это в каком-нибудь FLTK или другом легковесном тулките реализовано?

не знаю. можешь посмотреть их исходный код.

не знаю, что такое QSS

Очередной велосипед от qt, попытка сделать CSS из веба.

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

Но ведь масштабируемость можно через костыль реализовать: есть у нас картинки виджетов в большом разрешении, переконвертируем их под нужный масштаб единожды и используем их повсеместно. Для уменьшения нагрузки на диск можно генерировать спрайты как в CSS (одна картинка за другой, отделяем их по заранее известным координатам). А через cairo приходится преобразовывать векторное изображение в растровое каждый раз, а может и для каждой кнопки - вот она просадка производительности или нет?

А через cairo приходится преобразовывать векторное изображение в растровое каждый раз

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

есть у нас картинки виджетов в большом разрешении, переконвертируем их под нужный масштаб единожды и используем их повсеместно. Для уменьшения нагрузки на диск можно генерировать спрайты как в CSS (одна картинка за другой, отделяем их по заранее известным координатам).

это займет много места на диске и в памяти.

Ресайзинг растрового изображения портит качество в любом случае. Даже если мы уменьшаем картинку. Только на больших разрешениях (типа преобразования 1080p в 720p) и кратных размерах это практически незаметно. А вот когда размеры не кратные и размеры порядка бегунка на сколлбаре, то будут дикие артефакты. Вектор лишён этого недостатка. А виджеты могут потребоваться любых размеров. Плюс качественный ресайзинг не такая уж лёгкая операция, нарисовать несложный вектор будет менее накладно.

PNG привел как поддержку прозрачности

false.

«Прозрачность» - это лишь маска, альфа-канал, важно то, как его интерпретирует (или поддерживает) отображающая сторона.

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

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

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

для отрисовки всего экрана с разрешением 1920x1080 композитору придется выделить буфер примерно такого размера

несколько буферов, swap chain. и выделяет их, как правило, не композитор, а драйвер фреймбуфера - композитор просто открывает соответствующее устройство и получает доступ к (непрерывной) памяти

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

Векторная отрисовка виджетов нужна только для округленных виджетов? Квадратиши можно и вручную рисовать? Т.е. нужна кнопка 50х100, бежим по циклу и рисуем толстелькую линию в буфере, а потом отдаем на вывод?
Но ведь вставляются иконки в программу: одной больше, другой меньше.. Даже если забить на тени, то получается: начало/конец/ползунок скроллбара, верхняя/нижняя/левая/правая_полоса/угол кнопки - вот 2 основных примитива. Ну пускай на 5МБ процесс жрет больше, зато не нужно ничего рендерить и тратить на это такты процессора. Как идея?

Ресайзинг растрового изображения портит качество в любом случае.

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

рендерить и тратить на это такты процессора

какого именно процессора?

Ну те же поля ввода и комбобоксы вполне могут ресайзится при изменении размера окна (а у них есть рамочки, градиенты и т. д.). С layout'ми кнопки тоже вполне могут это делать. А тулкит должен поддерживать возможность построения любых интерфейсов. Кнопка, занимающая всегда определённый процент окна, может пригодится в каких-то случаях. Да можно просто вспомнить про мониторы с разным DPI. Если все элементы интерфейса (включая кнопки, полосы прокрутки и т. д.) будут масштабироваться в векторном виде, то интрефейс будет выглядеть значительно приятнее. Если этого не делать вообще (захардкодить все размеры), то на HighDPI дисплее всё будет жутко мелкое, если делать как в винде (растровое масштабирование), то получается дикое мыло и в итоге на мониторе с низким DPI изображение качественнее, чем на HighDPI, чего быть не должно. Конечно, можно свято верить, что DPI всегда равен 96, кнопочки всегда имеют одинаковую высоту и пикселях и это не может измениться в ходе работы программы (то что в иксах иногда глючит определение DPI и нет возможности поменять его при подключении нового монитора без перезапуска приложения-клиента - проблема иксов, это не значит, что тулкитам надо забить на эту возможность, благо Wayland на подходе), но уже сейчас есть ситуации, когда это не верно.

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