LINUX.ORG.RU

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

 , ,


0

3

Дисклаймер. В связи с тем, что очень многие (почти все) здесь не понимают, зачем нужен Wayland, пишу в новости, благо есть источник, где кое-что разжёвано. Текст чуть-чуть подсократил, чтобы не захламлять.

Итак, приступим.

  1. В Wayland может быть реализована сетевая прозрачность.

    Это дело конкретного композитора. Всё дело в ошибочном понимании фразы «в Wayland нет сетевой прозрачности». Правильное понимание этой фразы таково: «спецификация Wayland не занимается сетевой прозрачностью и не определяет её». Композиторы могут быть выполнять локальную отрисовку, могут быть сервером и передавать картинку по сети (хоть на много машин одновременно), а могут делать и то и другое. Те, кто думают, что в Wayland сетевой прозрачности быть не может вообще, ошибаются.

  2. Сетевая прозрачность X11 не подходит для современных приложений.

    Она давно устарела, будучи сделанной с расчётом на то, что приложения используют простые команды для отображения содержимого окна, и эти команды можно отправлять по сети. Когда-то это было разумно, но современные приложения не используют X11 для рендеринга, они используют такие технологии как Cairo, Clutter, QPainter (Raster) или OpenGL. В этом случае X11 вынужден отправлять по сети готовую картинку, а для этой ситуации есть технологии, которые делают это гораздо лучше, чем X11. Сетевая прозрачность в X11 померла и так, без участия Wayland.

  3. X11-приложения будут поддерживаться.

    Никто не хочет ломать систему, переход на Wayland будет произведён если и только тогда, когда X11-only приложения будут в ней хорошо работать (через слой совместимости). Сетевую прозрачность X11, очевидно, тоже можно будет использовать.

  4. Сетевой прозрачности не место в оконной системе. Если вы хотите быстрой сетевой прозрачности, ей место в тулките виджетов.

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

  5. «Дистибутивы выкинут иксы, моё любимое X11-only приложение не заведётся!»

    Для этого уже есть слои совместимости (X11 приложения можно запускать из композитора Wayland). Поддержку X11 никто не выкинет из дистрибутивов, пока она будет востребована, даже Mac OS X всё ещё поддерживает X11 для совместимости. Постепенно количество X11-only приложений будет уменьшаться (переписывание, естественная смерть), и даже если из вашего дистрибутива поддержку X11 уберут, вы всегда сможете её собрать сами.

Прекратите повторять ошибочные утверждения.

P.S. Отвечу на вопрос «Зачем вообще нужен Wayland, давайте улучшать X11».

Такие (или аналогичные) изменения даже если были бы возможны в X, всё равно бы сломали X11 и дали несовместимый с ним X12. Без слоя совместимости обойтись невозможно, а сам X12 тоже был бы не сахар, так как писался бы с оглядкой на X11. И чем это было бы лучше того, что мы имеем с Wayland?

В основе X11 лежат архитектурные решения более чем двадцатилетней давности (см выше). Так делать уже не надо, очень много функциональности иксов перешло в тулкиты, ядро, D-Bus, и другие системы. Замену легче написать с нуля, которая делает только свою прямую работу, а не пытается объять всё.

>>> Подробности

★★★★★

Проверено: svu ()
Последнее исправление: cetjs2 (всего исправлений: 11)
Ответ на: комментарий от ChALkeR

Хорошо, что уточнил - «локально».

А по сети оно перерисовывается жутко медленно, в отличие от шустро работающего «native».

Да, X forwarding хорош тем, что приложения встраиваются в рабочее окружение на другой системе, в отличие от всяких VNC.

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

Если в Wayland будет всё то же, что и в иксах, но быстрее, проще и лучше, то пусть будет и даже пусть внедряется.

После тщательного тестирования.

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

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

Native — шустр по сети? Ты хорошо пошутил.

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

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

Ещё раз повторяю: в иксах была качественная работа по сети как надо, но она в современных реалиях очень убога и её явно не хватает для приличной картинки. И не будет хватать в принципе. Работа по сети должна быть перенесена в тулкиты. Она, собственно, и так требовала поддержки в тулкитах (тот же native), если не хотелось гнать растр.

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

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

При этом если поддержки в тулкитах нет — должен быть способ гнать растр, как и в иксах. Вот это уже можно сделать в рамках специального композитора Wayland.

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

> Native — шустр по сети? Ты хорошо пошутил.

и т.д.

Я не шучу. У меня ZyGrib тот же работает в native по сети (5 мегабит с включённым на раздачу торрентом) почти неотличимо от локальной копии. В raster - меедленная загрузка интерфейса приложения как картинки построчно, которая на каждый чих обновляется. Thunderbird, Eclipse, Pidgin, pgadmin работают опять-таки почти неотличимо от локальных приложений по скорости.

Да, совершенно серьёзно - быстрее чем VNC без lossy сжатия! Сжатие с потерями раздражает левыми цветами и мыльными шрифтами.

В игры не играю, видео смотрится локально хорошо. Потому для меня лично актуальность Wayland и выкидывания native из QT не особо понятны.

P.S. Утверждения, что сейчас X forwarding работает жутко, не подтверждаются личным опытом, сколько раз ни повторялись бы. По крайней мере - остальное ещё хуже.

А то, что всегда есть что улучшать - это да.

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

> А то, что всегда есть что улучшать - это да.

На самом деле будет хорошо, если Wayland таки станет - стандартным, переносимым, лёгким, быстрым, простым и функциональным, при этом заменит или дополнит X Window System на десктопе.

Однако, здоровый консерватизм (не ломай работающее) редко когда мешал.

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

Значит, ты ошибаешься. Да, Native быстрее по сети, чем Raster. Но сам Native тоже очень медленный.

Не всё хуже. Запусти программу, использующую Xaw и сравни.

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

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

>Thunderbird, Eclipse, Pidgin, pgadmin работают опять-таки почти неотличимо от локальных приложений по скорости.

Два хеннеси этому господину

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

>Если ты ещё не понял: 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ChALkeR ★★★★★
() автор топика
Ответ на: комментарий от baka-kun

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

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

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

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

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

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

>Вообще в огл есть отличная штука в виде 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-сервере, мы только создаем нужные объекты и командуем, что и с чем композитить, откуда брать и т. д.

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кто? Тут 30 страниц криков «Иксы не нужны». Про медленно обманули тебя. :)

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

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

Это лишняя сущность.

В схеме с модулем: тулкит → специальный бэкенд для поддержки модуля (локально его использовать — зло, см выше) → прослойка (модуль в иксах в случае иксов) → сеть → рендеринг на клиенте тулкитонезависимым способом.

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

У первого варианта плюс может быть один: рендеринг будет независим от тулкита. Такое разделение логики и представления почти автоматически даст возможность рендерить Qt-приложения через GTK-морду и наоборот. Но с этим и так-то туго, без работы по сети, так что это очень маловероятно. Я сомневаюсь, что разработчики тулкитов договорятся о единой высоуровневой прослойке для отрисовки всего (низкоуровневые, по сравнению с тем, про что я говорю, вроде XRender, не особо интересны), а без неё твоя схема нереализуема. Но если договрятся — то это тоже хороший вариант, даже очень.

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

Разница именно в нереальности первой схемы.

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

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

>Декорации окна силами самого приложения? Вы это серьёзно? И эти люди против зоопарка...


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

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

>Когда будут хотя бы драфты, тогда и будет, что обсудить.

Им наверно у тебя нужно было спросить с чего начинать чтобы ты мог обсудить а не осудить, корона не жмет ? ;-)

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

В прямом, HTML нормально всё рисует, использует кеширование, не тормозит, при этом далёк от идеала — многое, очень многое делается ненавистными вам пиксмапами, и никто не умер, этот ваш веб живёт и здравствует и подыхать, к сожалению, не собирается.

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

Кто их осуждает? Не сочиняйте, пожалуйста.

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

>Ясно что в протоколе должен быть механизм при помощи которого клиент и сервер договариваются — кто из них занимается декорацией окон.

X сервер не занимается декорацией окон.

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

что html нормально рисует? когда это html умел кешировать? (если забыть про local storage из html5). От идеала он не просто далек, а ужасно далек, поскольку действующие стандарты с одной стороны никого не устраивают и каждый приделывает те фичи, которые ему нравятся и хочется. с другой стороны почти никто действующие стандарты толком не поддерживает. (сколько лет понадобилось, чтобы простенькие тесты браузеры начали в соотвествии со стандартами показывать?)

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

Я прекрасно понимаю все его недостатки, но ведь работает? Работает, вроде. А кеширование этих ваших пиксмапов на уровне HTTP вполне работает.

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

Веб-браузер вместо X11 это такой ужас и кошмар, что лучше этого будето что угодно, да хоть Windows XP.
Кстати, тебя никогда не смущал тот факт, что твой браузер сжирает СОТНИ МЕГАБАЙТ ОЗУ?

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

Да, логичнее. Но тогда будет двойной расход памяти: в приложениях (оно в любом случае должно знать что нарисовано) и в иксах. А так иксы могут хранить только текущее состояние экрана. В win7(в интерфейсе aero) например окно не перерисовывается.

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

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

farafonoff ★★
()
Ответ на: комментарий от quantum-troll

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

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

«Тут 30 страниц криков „Иксы не нужны“.»

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

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

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

Ну и второе, было бы желание, но нынче все гонят время, надо быстрее и быстрее, оттуда и веб этот костыльный выполз, потому что людям надо сделать чтобы работало с наименьшими затратами, а дальше — хоть трава не расти. А ведь если SaaS и имеет право на жизнь, то через протокол, похожий на X11, но никак не через HTTP. Сугубо моё ИМХО, конечно.

Binary ★★★★★
()
Ответ на: комментарий от quantum-troll

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

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

> А тебе никогда не приходило в голову, что баг не правят, потому что никого, кроме как троллей, он не задевает?

Баг есть баг. В трекере он есть, тролли написали даже частичный патч, а нормальный патч невозможен. Кроме того, переключалка нужна лишь малому числу пользователей линукса вообще, что ее теперь - выкинуть совсем?

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

> Да, логичнее. Но тогда будет двойной расход памяти: в приложениях (оно в любом случае должно знать что нарисовано) и в иксах.

Поверь мне, я предпочту перерасход памяти, если это поможет избавиться от морганий в 99% криво написанных приложений.

И уж тем более — при подключении с другой машины.

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

> Ты плохо меня читал. Я везде разделял разные способы сборки картинки.

Ладно-ладно. Уговорил.

По сравнению с уровнем, используемым в тулкитах, это всё баловство.

Вот тулкитами и надо заняться. Вейланд тем более не нужен.

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

> Хотя они в общем являются зависимыми от реализации X Server

У нас де-факто только одна распространённая реализация иксов. :)

У меня, например, Backing Store включен (судя по логу и по тому, что возвращает X Server в структуре при авторизации), но мое игрушечное приложение что-то не очень-то восстанавливает окно.

Вроде бы в xorg его сломали/выпилили. Мотивируя тем, что эта фича устарела, и нужно юзать композитинг.

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

Что тулкитами надо заняться и впилить в них нормальную сетевую прозрачность — факт. Благо модульность систем отрисовки сильно облегчает задачу.

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

> В схеме, о которой говорил я: тулкит → специальный бэкенд для работы по сети → сеть → рендеринг на клиенте тем же тулкитом.

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

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

Почему «иксы»? Иксы — (провалившаяся со временем) попытка написать универсальный стандарт для отрисовки по сети.

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

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

> Баг есть баг. В трекере он есть, тролли написали даже частичный патч, а нормальный патч невозможен. Кроме того, переключалка нужна лишь малому числу пользователей линукса вообще, что ее теперь - выкинуть совсем?

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

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

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

Универсальную.

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

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

>> Хотя они в общем являются зависимыми от реализации X Server

У нас де-факто только одна распространённая реализация иксов. :)

Да, но версии этой распространенной реализации тоже друг от друга отличаются. :) К тому же, в спецификации четко написано, что сервер *на свое усмотрение* [внезапно] может перестать задействовать backingstore (например, памяти мало или еще что-то там), поэтому нужно быть всегда готовым к событию Expose:

While the X server maintains the window's contents, Expose events normally are not generated, but the X server may stop maintaining contents at any time.

Вроде бы в xorg его сломали/выпилили. Мотивируя тем, что эта фича устарела, и нужно юзать композитинг.

Вот я эти разговоры из рассылки помню, да. Кейт Паккард предлагал по умолчению включить Composite Extension именно для backstore. Я деталей не помню, но утверждалось, что это даже лучше и красивее. Однако сечас у меня сервер старый, потому даже не знаю какова ситуация. И Composite включен, и backingstore включен. Я пару раз проверил и отложил.

Я также собираю сервер из Git, но только для целей сопровождения нужного мне кода, поэтому я собираю его с минимально неободимыми фичами. Подправлю сборку потом и проверю. А то окажется, что ищу черную кошку в темной комнате, когда ее и нет вообще. :)

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

> поэтому нужно быть всегда готовым к событию Expose

Как бы, я вел речь не о том, надо ли не реагировать на Expose, а о том, чтобы не дергать Expose без надобности, если у нас видеопамяти навалом. :)

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

Его починка противоречит документации на xkb, и об этом сказано в обсуждении того бага.

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

Да хоть xml перегонять, разделить библиотеку на две части не составляет труда. Сложно убедить договориться авторов нескольких таких библиотек, что и не будет нужно.

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

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

Отключение JS в хромом снижает потребление памяти примерно вдвое. Жги дальше.

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

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

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

> В тулките и так есть движок отрисовки. Обычно это что-то вроде каиро.

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

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

> В виндах иксы

Ты пропустил слово вменяемую.

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

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

Вопрос на засыпку: почему бы не заставить иксы это и делать при включении опции backing-store, без всяких внешних композиторов?

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

> Что-то из них лишняя сущность - или каиро или иксы.

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

Не в нашей вселенной.

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

> вдвое - с 500 до 250 мегабайт? ну я и говорю прожирание.

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

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

> Я привел как пример драфта протокола. здесь мог быть <любой другой универсальный протокол>

Ты сказал чушь, а не пример привел.

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

Я привел именно пример универсального протокола. Зачем создавать навороченный протокол, если клиент и сервер разрабатывают одни люди? Тулкитчикам _не_надо_ будет делать суперуниверсальный протокол, желательно только иметь обратную совместимость.

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

> Потому что дублирование памяти. Если у тебя запущена куча программ, расход памяти будет огромен.

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

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

>Я привел именно пример универсального протокола.
XML — не протокол. Хочешь поспорить — подумай, почему протокол для жаббера называется XMPP, а не XML.

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

> Я привел именно пример универсального протокола. Зачем создавать навороченный протокол, если клиент и сервер разрабатывают одни люди? Тулкитчикам _не_надо_ будет делать суперуниверсальный протокол, желательно только иметь обратную совместимость.

На эту тему ты с ChALkeR-ом говори.

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

> В древние времена можно было читать интернет и на 64х мегабайтах.

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

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

> Потому что видеопамять не считается.

Т.е. когда композитор использует видеопамять, это не считается. А когда сами иксы — то считается. Ты правда такой глупый или старательно гонишь дуру?

Тут считаем, тут не считаем, тут рыбу заворачиваем.

Она и так простаивает.

О боги, до тебя почти дошло!

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

>rpc
ЩИТО?!!! Ты таки хочешь примитивную логику гуя обрабатывать сервером (как js в браузерах)? Иначе нафиг тебе RPC вместо IPC?

когда это вызывало сложности?

Всегда, в общем-то.

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

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

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

Я не хочу обрабатывать логику гуя в сервере. Я хочу чтобы клиент говорил серверу нарисовать линию/градиент/закругленный прямоугольник с отражением и сервер это делал. В моем понимании это и есть rpc. А ipc это общее название для rpc и каналов связи между процессами.

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

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

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

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

Мне плевать на прозрачности и прочее. Меня интересует эффективность и отсутствие костылей.

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

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

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

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

ЩИТОЛОЛ?

Например, вот этот мануал по моим оценкам занимает около 10000 экранных страниц. При размере экранной страницы примерно 1264 * 906, его отрендеренная картинка заняла бы более 30 гигабайт, если я нигде не напутал с количеством нулей.

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

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

Ну и тем более. Можно было бы ввести необязательное управление прозрачностью окон как расширение протокола. Впрочем, на это мне тоже плевать.

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

Еще раз. Я не настаиваю на прозрачности - я говорю что backing store не использует видеокарту, по этому его заменили на композит который ее использует. Где я не прав?

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

Вопреки документации xkb этот баг был починен в Ubuntu, патч был принят так как не вызвал регрессий. Но дело в том, что починен этот баг только в Ubuntu.

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

> Вопреки документации xkb этот баг был починен в Ubuntu, патч был принят так как не вызвал регрессий. Но дело в том, что починен этот баг только в Ubuntu.

Вокруг xkb можно много багов найти. Какой именно баг?

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

> А на какой баг тут давали ссылку помните?

Разумеется, не помню. Этому треду уже недели три.

Если на вот этот: https://bugs.freedesktop.org/show_bug.cgi?id=865 , то в elementary комбинация alt-shift по-прежнему мешает хоткею alt-shift-tab, буквально вчера проверял. Сейчас еще проверю в чистом ubuntu 10.10. Более свежего не установлено.

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