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)

Ответ на: комментарий от 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 ★★
()

Был в начале века такой громкий проект Berlin Project,«убийца X-ов», где каждое приложение в своём композитном пуле, взаимодействие по своему протоколу, отрисовкой занимается отдельный виджетный фреймворк (тогда упор был на freesco, но и qt отметились).
За дело тогда принялись горячо: две команды создали композитные менеджеры beryl и fussion. у Qt появилась своя ветка -bp, но.. но больше ничего создано не было, а именно сервер взаимодействия видеодрайвер-видеоресурсы, который собственно и должен стать ядром новых технологий B-P.

Вычистив остатки биндингов не взлетевшего B-P, композитные менеджеры слились в compiz, который мы и имеем сейчас.

Через 7 лет, кто-то снова откопал B-P, решив, что виджетные фреймворки развиты и практически готовы форкнул композитинг компиза, переосмыслил протокол и застрял. А застрял на том, на чём умерло откопанное - нужно делать если не сервер, то ресурсный менеджер.

Не взлетит оно с оглядкой на иксы, также как и родитель.

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

А еще приложение должно корректно обрабатывать отваливание того и другого. Вопрос как приложение обработает отваливание рисовалки?

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

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

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

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

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

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

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

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

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

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

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

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

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

> Вопрос как приложение обработает отваливание рисовалки?

Никак. Приложению об отваливании рисовалки знать вообще не обязательно. С рисовалкой оно взаимодействует по тем же принципам, что и с другими агентами на шине: получил сообщение, обработал, послал широковещательное сообщение обратно.

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

> Особенно круто будет со всякими shm, drm и прочими расширениями.

Ну значит клиент пересоздаст соответствующие объекты по запросу сервера на переконфигурацию рисовалки. Делов-то.

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 ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.