LINUX.ORG.RU

Ответ на: комментарий от Zubok

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

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

geekless ★★ ()
Ответ на: комментарий от geekless

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

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

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

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

PolarFox ★★★★★ ()
Ответ на: комментарий от ckotinko

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

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

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

geekless ★★ ()
Ответ на: комментарий от Zubok

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

x3al ★★★★★ ()
Ответ на: комментарий от PolarFox

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

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

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

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

geekless ★★ ()
Ответ на: комментарий от geekless

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

PolarFox ★★★★★ ()
Ответ на: комментарий от PolarFox

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

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

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

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

geekless ★★ ()
Ответ на: комментарий от kss

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

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

Thero ★★★★★ ()
Ответ на: комментарий от PolarFox

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

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

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

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

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

PolarFox ★★★★★ ()
Ответ на: комментарий от geekless

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

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

Zubok ★★★★★ ()
Ответ на: комментарий от x3al

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

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

KivApple ★★★★★ ()

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

x3al ★★★★★ ()
Ответ на: комментарий от geekless

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

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

Zubok ★★★★★ ()
Ответ на: комментарий от geekless

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

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

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

ckotinko ☆☆☆ ()
Ответ на: комментарий от geekless

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

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

red_eyed_peguin ()
Ответ на: комментарий от geekless

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

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

red_eyed_peguin ()
Ответ на: комментарий от red_eyed_peguin

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

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

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

geekless ★★ ()
Ответ на: комментарий от x3al

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

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

red_eyed_peguin ()
Ответ на: комментарий от geekless

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

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

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, чтобы асечка не тормозила» под одобрительные вопли хомячков.

red_eyed_peguin ()
Ответ на: комментарий от PolarFox

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

ckotinko ☆☆☆ ()
Ответ на: комментарий от red_eyed_peguin

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

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

ckotinko ☆☆☆ ()
Ответ на: комментарий от red_eyed_peguin

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

Худей.

geekless ★★ ()
Ответ на: комментарий от geekless

Худей.

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

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

red_eyed_peguin ()
Ответ на: комментарий от red_eyed_peguin

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

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

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

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

geekless ★★ ()
Ответ на: комментарий от geekless

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

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

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

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

red_eyed_peguin ()
Ответ на: комментарий от red_eyed_peguin

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

PolarFox ★★★★★ ()
Ответ на: комментарий от PolarFox

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

Ну включи мозги: приложению нужна новая текстура, потому что менять отправленную в композитор он не имеет права, а рисовать может понадобиться прежде чем композитор закончит с нужной текстурой. Это же в самой архитектуре вяленого описывается: 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.

red_eyed_peguin ()

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

vasilenko ★★ ()
Ответ на: комментарий от red_eyed_peguin

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. В иксах оно происходит по-другому?

x3al ★★★★★ ()
Ответ на: комментарий от x3al

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

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

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

red_eyed_peguin ()
Ответ на: комментарий от red_eyed_peguin

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

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

geekless ★★ ()
Ответ на: комментарий от annulen

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

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

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

cruxish ★★★★ ()

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

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

ZenitharChampion ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.