Wayland 0.95.0 released

Ну так из pixmap тоже можно сделать texture, если вдруг надо. :)

Это понятно. Но «по дефолту» мы ведь используем xrender для рисования в тулкитах, а весь поток команд xrender идёт через сокет, что на локальной машине не оптимальено.

Вообще API отрисовки лежит за пределами Wayland. Это может быть OpenGL, OpenVG или любой другой API, контекст на который может выдать приложению та прослойка, которая передаёт буферы из клиента в сервер.

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

Ведь если, к примеру, у нас приложение рисует каким-то хитрым софтварным алгоритмом, то тогда нам надо каждый апдейт содержимого окна делать преобразование из пиксмапа в текстуру? Кто этим будет заниматься? Клиент? Сервер?

Блин, я не понимаю как обустроена работа с вейлендом со стороны клиента.

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

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

Это в теории. А на практике это насколько трудоемко провернуть? Нужна соответствующая допилка драйвера?

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

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

Для этого видимо фабрика wl_shm предназначена в API. Клиенту выдаётся кусок реальной ОЗУ, он туда себя программно рисует, после чего композитор запиливает буфер на видеокарту.

Ведь если, к примеру, у нас приложение рисует каким-то хитрым софтварным алгоритмом, то тогда нам надо каждый апдейт содержимого окна делать преобразование из пиксмапа в текстуру? Кто этим будет заниматься? Клиент? Сервер?

Если я правильно понимаю, то сервер.

Кстати вейландоразрабы упорно утверждают, что вейланд — всего лишь протокол, реализаций которого можно наплодить великое множество. И тогда можно запилить композитор, работающий… ну к примеру софтварно. А клиенты будут пытаться рисовать через опенгл и подсовывать текстуры. Или композитор принципиально должен работать с видеокартой? А если у нас её нет? Городить что-то вроде llvmpipe?

Блин, я не понимаю как обустроена работа с вейлендом со стороны клиента.

Насколько я понял сегодня из тех ссылок, что тут были:

Клиент просит сервер выдать ему буфер. Сервер инициализирует контекст в драйвере, заворачивает информацию в wl_buffer и передаёт клиенту. Клиент скармливает полученный wl_buffer драйверу и получает контекст, в который может рисовать при помощи некоторого графического API. Когда клиент всё нарисовал, он сообщает серверу, что пора surface окна обновить из буфера.

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

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

ЗЫ в целом это несущественная вещь, из-за такого мечети не взрывают.

Эээ... не знаю. На клиенте должно быть нечто, что скажет высокоуровнему коду (тулкиту, например), через какие API можно рисовать и как именно. Если нам дали буфер в ОЗУ, значит инициализируем, например, в cairo бэк-энд, рисующий в ОЗУ — и вперед...

Если дали буфер в реальной видеопамяти, инициализируем в cairo бэкэнд OGL или OVG, или что там еще бывает.

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

• Приложение через dbus спрашивает, на каком сокете искать сервер трея.
• Реализация трея отвечает адресом своего сокета.
• Приложение подключается туда по протоколу wayland и рисует свою иконку.
• Трей берет буферы всех присоединившихся к нему приложений, рисует в своё окно и передаёт в другой вейланд сервер. Обратно пересылает события ввода.

Не нравится мне подобный API. Он какой-то не слишком APIтистый. За счёт упрощения в одном месте получаем резкое усложнение в другом. Причём ситуация с усложнённым сервером имхо лучше, чем с усложнёнными клиентами, потому что клиентов банально много, а сервер один.

В случае иксов если ты используешь 2D-ускорение (Xrender), у тебя команды идут через сокет — лишняя нагрузка на переключение контекстов.

А буферизация?

init + ядро < init + ядро + wayland.

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

А сколько там буферизуется?

Тем временем прямо сейчас к wayland-версии glxgears добавляют отображение FPS. Ждём сравнение на форониксе.

А сколько там буферизуется?

Ну, в xlib не знаю. В XCB #define XCB_QUEUE_BUFFER_SIZE 16384, в CLX, кажется 4096 байт (проверять надо). У меня в x11-el вообще пока нет буферизации - только емаксовская на 500 байт где-то. :)

А на практике это насколько трудоемко провернуть? Нужна соответствующая допилка драйвера?

да, нужна. даже не драйвера -это скорее общая часть будет.

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

В Wayland ты загрузишь его как текстуру OpenGL

Отличное решение. Теперь в минимальные требования для кривого гуи линакса будет входить «от 2GB видеопамяти»?

весь поток команд xrender идёт через сокет, что на локальной машине не оптимальено

Что примечательно, на вяленде ситуация никак не меняется в лучшую сторону: и сейчас можно самостоятельно готовить пиксмап в shared memory, а потом просить иксы отрисовать его (так работает wine, кстати; вспоминаем флейм «firefox в wine работает быстрее нативного линаксового»). Ах, да, Qt тоже так умеет. Но нам же надо велосипеды городить.

Что примечательно, на вяленде ситуация никак не меняется в лучшую сторону: и сейчас можно самостоятельно готовить пиксмап в shared memory, а потом просить иксы отрисовать его

Вижу, что про видеопамять в вашей вселенной еще не слышали.

Иди учи матчасть.

Тем временем прямо сейчас к wayland-версии glxgears добавляют отображение FPS. Ждём сравнение на форониксе.

Сравнивать надо на нормальных проприетарных драйверах, а не опенсорсных хеллоуворлд.ko.

Вижу, что про видеопамять в вашей вселенной еще не слышали.

А что не так с видеопамятью? Специально для эльфляндии:

1. С помощью GLX можно рисовать offscreen video memory — нет принципиального отличия от вяленда.

2. Рисовать софтварно попиксельно в видеопамяти — бред и тормоза, поэтому любой «software rendering» сводится к в конечном итоге к «рисуем в RAM, копируем в видеопамять, переключаем страницы».

3. Сейчас у меня 3 полноэкранных окна 1920x1080 и иксы потребляют 16 мегабайт. Вяленый вынудит каждое такое приложение держать запасной буфер, итого потребление подскочит до (1920 * 1080 * 3) * 3 * 2 (идеальный мир, 24bpp) = 35 мегабайт только для клиентов, а еще самому вяленду нужно иметь как минимум два буфера для композитинга, итого где-то в районе 45-50 Mb потребуется только для отрисовки трех окошек. Линакс уверенно продолжает катиться в сторону «8 GB RAM, чтобы асечка не тормозила» под одобрительные вопли хомячков.

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

нормальных проприетарных

/0

он работает через GLES2. т.е. в видеопамяти лежат текстуры. еще раз - в видеопамяти. и управляет ими DRI, у которого есть команда flip. а

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

конечные картинки нужно положить туда, где их достанет композитор. для 100% софта - это shm. для hardware - видеопамять

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

А TTF шрифты в линаксе сейчас по-твоему кто отрисовывает?

Тебе чтобы один раз глиф отрисовать и закинуть результат в текстуру, нужен в ОЗУ буфер «полноэкранного окна 1920x1080»?

Худей.

Худей.

Дядя, по два здоровых буфера на одно клиентское окно тебе понадобятся как ни крути. Единственная оптимизация — это клиент будет говорить вяленому среверу: «у меня обновилась воот эта часть окна». Если ты собираешься по одному глифу передавать запихивать в видеопамять — это не просто lol, а целый rofl.

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

Если ты собираешься по одному глифу передавать запихивать в видеопамять — это не просто lol, а целый rofl.

Внезапно, gtk через xrender так и делает. Только при этом еще и насилует иксы через сокет. Тебе серьёзно надо с матчастью ознакомиться, прежде чем троллить тут.

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

В ОЗУ? Да ты упорот. Вся отрисовка пойдёт аппаратно.

Внезапно, gtk через xrender так и делает

И откуда ты почерпнул этот бред?

В ОЗУ? Да ты упорот. Вся отрисовка пойдёт аппаратно.

Ты точно наркоман. Будут две копии либо в RAM, либо в видеопамяти, причем если оперативочки сейчас несложно и 16 воткнуть, с видеопамятью все несколько сложнее. Правда на текущих разрешениях можно и стерпеть 200-300Mb video RAM на рендеринг рабочего стола с парой десятков окон.

x11trace в зубы — и вперёд.

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

В сферическом случае в вакууме

Ну включи мозги: приложению нужна новая текстура, потому что менять отправленную в композитор он не имеет права, а рисовать может понадобиться прежде чем композитор закончит с нужной текстурой. Это же в самой архитектуре вяленого описывается: http://wayland.freedesktop.org/architecture.html

Render the new content into a new buffer and tell the compositor to use that instead of the old buffer. The application can allocate a new buffer every time it needs to update the window contents or it can keep two (or more) buffers around and cycle between them. The buffer management is entirely under application control.

Таки обесните, что в нём будет использоваться для работы по сети? Тупое VNC?

Render the new content into a new buffer and tell the compositor to use that instead of the old buffer. The application can allocate a new buffer every time it needs to update the window contents or it can keep two (or more) buffers around and cycle between them. The buffer management is entirely under application control.

Тут описан double buffering. В иксах оно происходит по-другому?

В иксах оно происходит по-другому?

Тут описан не double buffering, а единственно возможный вариант работы с вялендом: подгоняется картинка всего окна. Насколько я понял, в целях оптимизации можно только сказать: «окно изменилось только вот в этом месте».

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

Ага — и при этом для отрисовки тулкит всё равно использует double buffering.

А приложения без double buffering дико моргают содержимым окна. (worker, например, или приложения на FOX toolkit.)

С чего бы им исчезать? Приложения - это не только стопицот калькуляторов и плееров.

Вот из-за таких мы и имели 32-битную оперу на qt3, и до сих пор имеем кривой 32-битный скайп.

Хочешь, чтобы твоим софтом пользовались - будь добр, перепиши его с использованием *современных* технологий.

Development status Beta

> Иксокапец уже скоро!

Уже наступил. Ставь DirectFB.