Wayland — разъяснения от разработчиков KWin

>Если ты ещё не понял: Native шлёт пиксмапы.

А почему только пиксмапы? Я, конечно, не специалист в коде Qt, но предполагаю, что, например, градиенты они в XRender не выталкивают, а сами рисуют. Те примитивы, которые изначально картинки, те выталкиваются в виде картинок. Но и другие примитивы XRender посылаются: глифы, трапезоиды, прямогульники. Это если верить давней записи Zack Rusin [1] по поводу 2D в KDE (запись [2] как раз говорит чуть-чуть про сетевую отрисовку), где он популярно расписывает картину с native vs raster vs opengl и объясняет причины, почему raster оказывается быстрее. Насчет примитивов, которые посылаются XRender, надеюсь, он не гипотетически говорит. Я не знаю, насколько хорошо Qt работает с XRender. Проблемы во многом лежат в драйверах, об этом тоже написано. Ситуация native vs raster — это компромис, opengl — вариант бескопромиссный. Хотя это еще надо посмотреть на случай, когда XRender в драйвере оказывается 100% ускоренным. Тогда вся отрисовка из GPU вылезать даже не будет. У XRender очень простой API по сравнению с OpenGL.

[1] http://zrusin.blogspot.com/2009/08/2d-in-kde.html

[2] http://zrusin.blogspot.com/2009/08/more-2d-in-kde.html

Ты так говоришь, как будто я этого не знаю.

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

Именно поэтому сетевой прозрачности место в тулкитах, только там будут рисоваться красивые интерфейсы (как сейчас у Qt/Gtk) со скоростью Xaw по сети.

Этот компромисс между левой и правой ногой приводит к тормозам везде.

Как, например, кнопочку со стилем или график отрисовать через XRender? Правильно — никак, то есть пиксмапом. Вот он и шлётся по сети.

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

XRender очень убог.

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

Это ложное заключение. Даже лживое. Если ты разберешь интерфейс по косточкам, то увидишь, что пиксмапами надо рисовать далеко не все. То, что надо рисовать пиксмапами (картинки, например) и так надо будет пиксмапами рисовать в любом случае, при любом ракладе, где бы сетевая прозрачность не была бы расположена. Картинку терминальный клиент не выдумает. А вот то, что элементы интерфейса могут быть построены на основе картинки (например, полоса прогресса очень хитрой текстуры), так ты вот можешь в случае X11 кусочек этой текстуры сохранить, а потом по сети командовать, чтобы сервер из нее полосу рисовал. Пиксмапы, еще раз повторю, это объекты, которые используются многократно, а вот обновляемые области, которые по RFB идут, не могут быть заново использованы.

Насчет Xaw ты тоже лжешь. Он специально так был написан, чтобы при отрисовке использовались примитивы из X11 core. Более другие способы отрисовки продемонстрировали более поздние тулкиты.

Возможно они и хотят отделить графику от IPC, а IPC повесить на dbus. для звука в «десктопных» дистрах есть пульсаудио. Сетевую прозрачность убунтовцы впилят в гтк, если захотят, и потом можно будет собрать все это в одну кучу и получится юникс-вейная сетевая прозрачность :)

Вообще в огл есть отличная штука в виде display list - можно один раз отрисовать объект в нем, а потом командовать его рисовать. По идее идеальное расширение примитивов. Не знаю умеет XRender такое или нет.

> Как, например, кнопочку со стилем…

Один раз за сессию при рисовании самой первой кнопки будет послано по четыре маленьких картинки углов кнопки (4х4..8х8 пикселей, не больше) и четыре ещё меньших — стороны рамки (две 4х1..8х1 и две 1х4..1х8) для каждого состояния кнопки (ховер, даун,…). Внутренности кнопки будут нарисованы либо командой градиента XRender, либо масштабированием с помощью XRender ещё одной картинки размером около 16х16 пикселей. Текст внутри кнопки будет составлен из переданных на сервер глифов.

При этом все примитивы: рамка, фон, глифы, иконки,… будут закешированы на сервере, и следующая кнопка будет нарисована командами.

или график отрисовать через XRender?

Смотря что за график, зачем обязательно XRender? Нет, можно тесселировать картинку и передать, при этом умный тулкит получит приличную экономию на однотонных областях. Но никто не мешает нарисовать график либо примитивами иксов, либо с помощью OpenGL. Кстати, Qt, например, умеет все три способа.

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

Вот, например:

Насчет Xaw ты тоже лжешь. Он специально так был написан, чтобы при отрисовке использовались примитивы из X11 core. Более другие способы отрисовки продемонстрировали более поздние тулкиты.

А я что, по твоему, сказал?

Цитату, пожалуйста.

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

>>Насчет Xaw ты тоже лжешь.

А я что, по твоему, сказал?

Я про то, что, по твоему мнению, все, что дальше Xaw — это уже неизбежно пиксмапы. Это не так. Core Protocol'ом Иксы не ограничиваются. Есть еще XRender, и GLX.

Почитал я этот ваш тред и даже говорить ничего не буду. Просто бессмысленно говорить о столь мёртвой вещи. За последние полгода в git было произведено меньше 75 коммитов. То, что они там понаделали за все годы разработки, толпа студентов в MIT за полгода реализует. А за год этот продукт можно было бы в продакшн выпускать.

>Вообще в огл есть отличная штука в виде display list - можно один раз отрисовать объект в нем, а потом командовать его рисовать. По идее идеальное расширение примитивов. Не знаю умеет XRender такое или нет.

OpenGL — это весьма навороченная штука. OpenGL ES будет проще. Я предполагаю, что он сможет занять место XRender, хотя XRender еще проще. XRender — это всего 31 запрос на все: на рисование примитивами, на создание и формирование GlyphSet'ов, на применение фильтров, picture transformation, градиенты. В XRender примитивы (треугольники, прямоугольники, трапезоиды) не являются самостоятельными объектами. Объектами (то есть то, что получает XID) в XRender является Picture, PictureFormat, GlyphSet. Вот этими объектами (пока они живы) и идет манипулирование.

Например, надо создать градиент. Посылаем запрос на сервер «создай линейный градиент в прямоугольной области между двумя точками P1 и P2 с такими-то референсными точками (список прилагается в запросе)». Результат: X-клиент имеет Picture ID с этим градиентом. Этот градиент может быть создан при помощи GPU и лежать в Video RAM. Вот этим градиентом потом можно штопать оформление всяких кнопок.

Надо нарисовать, скажем, сложную кривую. На стороне клиента мы ее рассекаем на примитивы, список примитивов отправляем на сервер, там это все композитится на GPU в изображение, мы (X-клиент) имеем XID этого изображения. Имея, например, заранее созданную Picture (source) с градиентом, мы можем эти примитивы изобразить на другой Picture (destination) с этим градиентом из любого места исходной картинки (есть параметры src-x и src-y и маска). Все происходит на X-сервере, мы только создаем нужные объекты и командуем, что и с чем композитить, откуда брать и т. д.

>OpenGL — это весьма навороченная штука. OpenGL ES будет проще. Я предполагаю, что он сможет занять место XRender

Криво написал, не проверил. Я имею в виду, что OpenGL будет все чаще использоваться как бекенд для 2D, так как карточки развиваются. Но, честно говоря, мне трудно пока сказать, как будет соотноситься трафик с XRender — OpenGL (GLX) весьма многословный.

> Вообще в огл есть отличная штука в виде display list - можно один раз отрисовать объект в нем, а потом командовать его рисовать.

/* звуки сирены */

ВНИМАНИЕ! ВНИМАНИЕ! ВСЕМУ ПЕРСОНАЛУ. СБОЙ В КРИОБЛОКЕ 29, ЯЧЕЙКА 246.

Не нашел сходу в интернете доков по xrender, вот и спросил. Интересно попробовать отрисовать красивые стилизованные кнопочки полностью через xrender(без пиксмапов) и потестить.

display lists — уже давно deprecated.

>с разработки адекватной сеансовой шины
Plan9 9P?

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

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


http://www.mail-archive.com/wayland-devel@lists.freedesktop.org/msg00641.html

Plan9 9P

Его сила в интеграции с ОС. Для линукса, это не более чем очередной транспорт.

Значит надо переходить на Plan9. :)
Canonical: Plan9 с человеческим лицом.

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

Ой, слушай, перестань. В приведенной ссылке речь вообще не о модели Иксов, а о чьей-то гипотетической идее описывать интерфейс в виде векторных моделей и грузить их на сервер, чтобы сервер сам все отрисовывал, когда надо перерисовать и не дергал сеть. Иксы не так работают! По ссылке речь не про Иксы. В Иксах окна при необходимости их перерисовки получают Expose event, по которому *X-клиент* сам заново рисует содержимое, используя при этом и примитивы, которые есть на сервере. Сервер самостоятельно никакого решения по перерисовке не принимает. В иксах перерисовка как раз client-side. Попробуй написать простое приложение для X, которое что-то выводит на экран, утащи окошко за границы экрана, а потом верни. Ты увидишь, что содержимое стерлось и не восстановилось.

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

Тем не менее это не отменяет ненужность иксов ;-)

Кстати насчёт Expose. Опции backing-store и save-unders сейчас еще актуальны? Разве не логичнее держать содержимое окон закешированным в video RAM, чем заставлять клиент перерисовывать окна при каждом изменении z-order и перемещении окон?

Почему это не используется по дефолту?

> Тем не менее это не отменяет ненужность иксов ;-)

Срочно чини свою логику.

>Срочно чини свою логику.

Если ты прочитаешь текст по ссылке то поймешь — все вполне логично, рендеринг на стороне клиента рулит — иксы не нужны.

>Не нашел сходу в интернете доков по xrender, вот и спросил.

По-моему с этого надо и начинать:

http://www.x.org/releases/current/doc/renderproto/renderproto.txt

Кто больше?

Рендеринг на стороне клиента рулит, потому что рендеринг на стороне клиента рулит.

Не находишь в этом ничего странного?

Я прошу цитату. Как именно я считаю, и откуда ты взял, что я так считаю?

По поводу XRender — ты хочешь сказать, что GTK или Qt могут рисовать исключительно через него, без каких-либо пиксмапов? Не верю.

С произвольным стилем, естественно, а не с одним конкретным.

> По поводу XRender — ты хочешь сказать, что GTK или Qt могут рисовать исключительно через него, без каких-либо пиксмапов? Не верю.

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

Прочитай уже в википедии про XRender. Прочитай спецификацию этого расширения от разработчика. Прочитай уже хоть что-нибудь.

Зачем GTK XRender, если в GTK нет альфа-канала?

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

А вот это притянуто. Там про блокировку, а можно её не делать, если рендерить независимо.

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

Ты не ругайся. Я знаю, как работает XRender. Ты прочитай сообщение, на которое я отвечал, не передёргивай.

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

Что в моём сообщении (которое ты процитировал) тебе показалось ошибочным?

>толпа студентов в MIT за полгода реализует.

Ну и где эта толпа студентов MIT? Почиму они не помогут вялому? Или если он ненужен, пусть помогут Х12 ниписать и переписать хсервер под него. Почему они ничего не делают?

> Что в моём сообщении (которое ты процитировал) тебе показалось ошибочным?

Да там всё сообщение откровенно ошибочно:

> По поводу XRender — ты хочешь сказать, что GTK или Qt могут рисовать исключительно через него, без каких-либо пиксмапов? Не верю.

Ты подумай мозгом: как можно рисовать через XRender, не используя пиксмапы, если XRENDER И СОЗДАН ДЛЯ РАБОТЫ С ПИКСМАПАМИ.

Прекрати, пожалуйста, веди себя адекватно...

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

По поводу XRender — ты хочешь сказать, что GTK или Qt могут рисовать исключительно через него, без каких-либо пиксмапов? Не верю.

Ты подумай мозгом: как можно рисовать через XRender, не используя пиксмапы, если XRENDER И СОЗДАН ДЛЯ РАБОТЫ С ПИКСМАПАМИ.

Давай формализуем.

Я говорю, не тебе «Ты что, думаешь, что A? Такого быть не может». Тут лезешь ты и заявляешь: «Как может быть A? Ты дурак!», и начинаешь изливать тонны говна.

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

Тебе по предикатам разложить?

 ты хочешь сказать, что => {
    GTK или Qt могут => {
         рисовать исключительно через него, без каких-либо пиксмапов
    }
} ?

«рисовать исключительно через Xrender, без каких-либо пиксмапов» есть чушь, т.к. Xrender с пиксамами и работает. По определению. Не веришь мне — открой википедию.

Или, другими словами, тебе тут уже давно пытаются объяснить, что X использует Y, а ты вопрошаешь: «неужели ты хочешь сказать, что X не использует Y?» Это либо тупость, либо троллинг, либо ты просто не читаешь сообщения собеседников.

Да ладно! Сколько уже было этих заменителей иксов - начиная с libSVGA и General Graphic Interface, заканчивая DirectFB и Qt Embedded.
Ну и где они все?

Во-первых, удали лишний комментарий.

Во-вторых, всё-таки прочитай пост, на который я отвечал. Зацитирую:

Я про то, что, по твоему мнению, все, что дальше Xaw — это уже неизбежно пиксмапы. Это не так. Core Protocol'ом Иксы не ограничиваются. Есть еще XRender, и GLX.

Вот я его и спросил, как он представляет себе отрисовку Qt через XRender без пиксмапов. Что не так?

Хорошо, как ты понимаешь вышезацитированное мной сообщение?

Дык. Еще на сообщение выше поднимись и посмотри, что сам писал до той реплики. «Твои» пиксмапы — это собирать картинку в тулките, а потом херакать её на сервер целиком. В то время как тот же Xrender предоставляет достаточно высокоуровнывый интерфейс для обработки их _на_ _сервере_. Не говоря уж об OpenGL. Это не тупо «гнать картинки», это вменяемое API.

Ты прицепился именно к моему ответу на ту реплику, и начал плеваться :). Он был обоснован и вызван той репликой.

«Твои» пиксмапы — это собирать картинку в тулките, а потом херакать её на сервер целиком.

Ты плохо меня читал. Я везде разделял разные способы сборки картинки. Зацитирую себя:

Шустрой по сети была бы чисто командная отрисовка. Без пиксмапов вообще. Вроде «используй такой-то стиль виджетов», «нарисуй кнопочку вон там». А native — убогий франкенштейн между тем, как надо в идеале (команды), и тем, как надо в случае, когда по-другому нельзя (растр, дельта, пожатый, или какие там алгоритмы).

Он тормозит по сравнению с тем, как надо, и локально и по сети.

В то время как тот же Xrender предоставляет достаточно высокоуровнывый интерфейс для обработки их _на_ _сервере_.

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

>Кстати насчёт Expose. Опции backing-store и save-unders сейчас еще актуальны? Разве не логичнее держать содержимое окон закешированным в video RAM, чем заставлять клиент перерисовывать окна при каждом изменении z-order и перемещении окон?

Да вроде бы актуальны. Хотя они в общем являются зависимыми от реализации X Server, сервер волен не делать backing store или выключить его. У меня, например, Backing Store включен (судя по логу и по тому, что возвращает X Server в структуре при авторизации), но мое игрушечное приложение что-то не очень-то восстанавливает окно. Если я указываю при создании окна backingstore в always, то Expose уже не шлется, но и изображение не восстанавливается. Либо это баг сервера (сервер старый), либо это я что-то не так делаю. Будем разобраться.

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

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

>В чём _необходимость_ убивания иксов так и не понятно, ибо архитектура позволяет делать всё это.

Насчет убивания иксов тебя кто-то обманул, а архитектура да, позволяет, только медленно :-) Кстати будет очень жаль если проект Wayland загнется из-за того что все уже есть и работает, тогда история ошибки 20-летней давности когда появилось ядро Linux которое уже «вот есть и работает» повторится.