Wayland 1.8

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

Так и запишем: «C - хипстерский язык».

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

facepalm.jpg

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

В итоге родят те же самые иксы, только ЕЩЕ ХУЖЕ.

О, любители минимализма подтянулись.

Ну а куда без нас.

Чем иксы утяжелены?

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

но наоборот содержат недостаточно фич, чтобы отвечать требованиям современности.

Да, например по безопасности.

Нет средств оптимизации вывода глифов

Единый шрифт, единый глиф, единый икс? Их там нет, потому что иксовым рендерингом шрифтов никто не пользуется. А не наоборот.

Нет средств проброски через единый канал доступа не только видео, но звука, принтера и других устройств.

Этого в иксах и не должно быть. Для этого есть spice, rdp и x2go. Причем x2go, использующий плюшки иксов для удалённой отрисовки тормозит не меньше остальных, а видео в нём это ад. Хотя с точки зрения простоты настройки он хорош.

Нет возможности сохранять состояние на стороне клиента при разрывах соединения.

Это надо, и хотят уже давно. И без ломки протокола не сделают.

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

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

потребности пользователей ограничиваются голым фреймбуфером.

От графической системы нужен только фреймбуфер + контроль ввода + удалёнка.

Чего в этой связке не хватает? Только конкретно, из того, что используется сейчас, а не фантазии.

тогда он должен быть не мне адресован, а разработчикам вейланда, они же, видите ли, сделали не по-Резетовски

Не вижу никакой современной основы в вейланде. Вижу старый-добрый фреймбуфер родом из начала 80-х.

так ты тоже не особенно изменился - был обезьяной ей и остался.

Извиняюсь за нубство, если что. Но не могли бы вы в двух словах объяснить зачем нужен wayland. На сайте сказано, что там несколько другая архитектура в которой чего-то там композитный менеджер размещен не сбоку, а внутри дисплейного менеджера судя по картинкам. Честно говоря не понял почему Х серевер нельзя было изменить таким же образом)

Разговор ни о чем. Главное, чтобы код эффективно работал и не имел багов.

Честно говоря не понял почему Х серевер нельзя было изменить таким же образом

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

Этого в иксах и не должно быть. Для этого есть spice, rdp и x2go. Причем x2go, использующий плюшки иксов для удалённой отрисовки тормозит не меньше остальных, а видео в нём это ад. Хотя с точки зрения простоты настройки он хорош.

Ути-пути! Ничего, что как раз рдп основан на богатом АПИ, что и позволяет серверу и клиенту знать состояние друг друга и обмениваться сугубо данными по делу, а не слать по сети тупо пожатые битмапы?

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

Обалдеть. В ответ на вопрос, чем иксы утяжелены я слышу, что они утяжелены ОТСУТСТВИЕМ контроля доступа. xD

Двойная буферизация это основа основ, в вейланде она ТОЖЕ есть. Сюрприз!

Базовое ускорение 2d есть в иксах, но нет в ейланде, который официальное НЕ ИМЕЕТ апи рисования. Типа это не его задача и вообще. Вместо того чтобы дорабатывать, выкинули нах. Ненуачо. Голову в песок это тоже решение. Тут вон графику из макоси упоминали выше. Вот почитайте, как она устроена, и какие там есть апи.

Забавно, что нужность 2д ускорения в одном посте сочетается с «рендеринг глифов сервером - не нужно».

Ну и так далее.

Лень комментировать всё остальное. Пойду лучше поужинаю. xD

Извиняюсь за нубство, если что. Но не могли бы вы в двух словах объяснить зачем нужен wayland. На сайте сказано, что там несколько другая архитектура в которой чего-то там композитный менеджер размещен не сбоку, а внутри дисплейного менеджера судя по картинкам. Честно говоря не понял почему Х серевер нельзя было изменить таким же образом)

Вейланд реализует концепцию разделяемого фреймбуфера. Он раздаёт клиентам полотна, в которые они рисуют. Потом он собирает эти полотна в общую картинку на экране. Сбоку к этому делу прикручена обработка ввода от мыши и клавиатуры.

Хорошая вещь для системы с ограниченными ресурсами типа телефона или морды управления каким-нибудь умным станком. Зачем она нужна на рабочих станциях, сторонники вейланда не могут объяснить вот уже лет 5.

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

Зачем она нужна на рабочих станциях, сторонники вейланда не могут объяснить вот уже лет 5.

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

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

Ну а что ещё делать, если современные тулкиты, такие как Qt и GTK, рисуют всё самостоятельно и по-минимуму зависят от X'ов? Раз уж сложилась такая ситуация, почему бы ей не воспользоваться?

У разработчиков иксов был шанс сделать вменяемое API рисования, которое бы соответствовало современности, но вместо это они дружно сказали «ненужно». А теперь они удивляются когда про иксы говорят, что это устаревший и ненужный хлам.

Этого в иксах и не должно быть. Для этого есть spice, rdp и x2go. Причем >x2go, использующий плюшки иксов для удалённой отрисовки тормозит >не меньше остальных, а видео в нём это ад. Хотя с точки зрения >простоты настройки он хорош.

Это было в протоколе и сейчас заброшено .Например было расширения для печати ,последними до 2005 года поддерживалась Sun и по соглашению Xerox .Своя логика тут есть ,Х протоколу по хрен куда выводить - на экран или на бумагу ,а железо в те времена стояло дорого ,«софт» принтера отнюдь не изобретении M$ .Вдобавок когда уже пошли нормальные сетевые принтера некоторые модели могли через сервер шрифтов подгружать нужные им наборы шрифтов.
Даже в Вики нет описание про протокол X-audio , если бы народ знал наверно не стали делать костыли в виде звуковых демонов .
Для медленных каналов (при удаленной работе ) было к сожалению изобретено 3 несовместимых между собой костыля для компрессии трафика -2 новых расширения и 1 программа прокси ,но работать даже по модему было можно .

Даже в Вики нет описание про протокол X-audio

А где тогда почитать?
Хм... вообще, не смотря на то, что это не unixway (пихать несколько сущностей в одно), это может иметь смысл для удаленной работы, чтобы картинка и звук были синхронными.

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

И для этого ему нужно быть частью протокола? Или он может быть просто одним из бэкэндов wm, как это сделано в weston'е? Ты что сказать-то хотел?

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

Двойная буферизация это основа основ, в вейланде она ТОЖЕ есть. Сюрприз!

Услышал знакомое слово, но не понял, что оно значит?

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

В иксах есть двойная буферизация на окно, в вэйланде нет.

Забавно, что нужность 2д ускорения в одном посте сочетается с «рендеринг глифов сервером - не нужно».

И что тебя забавляет? Нужность 2д ускорения для иксов - недостаток. А рендеринг шрифтов сервером не нужен. Т.к. им никто не пользуется, да и рендеринг плохой.

Вместо того чтобы дорабатывать, выкинули нах

Зачем дорабатывать то, что уже доработано в тулкитах?

Это было в протоколе и сейчас заброшено

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

Нет смысла встраивать всё в оконную систему. Быстрее от этого оно не станет, а сложнее в разы. Да и конкуренция должна быть.

Бэкэнд для отрисовки в принтер вещь интересная (правда где её применять не понятно). Но это всего лишь бэкэнд, ему не нужно быть частью протокола.

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

Вот тут мне хочется подробностей. Рассмотрим ситуауцию без композитного менеджера. По вашему, приложение хранит полное изображение окна, и Х сервер хранит полное изображение окна? Я правильно понял? Тогда почему если остановить приложение, то перекрытое другим, окно потеряет свое изображение и не будет восстановлено при перемещении верхнего окна? У сервера же есть картинка. Кстати, что тоже интересно, это справедливо не для всех тулкитов. ЕМНИП, изображение окна GNUStep сохранится.

А где тогда почитать?
Хм... вообще, не смотря на то, что это не unixway (пихать несколько >сущностей в одно), это может иметь смысл для удаленной работы, чтобы >картинка и звук были синхронными.

Про этот протокол я читал в man в дистрибутиве Slacware 2.0 .Нужно еще в форумах народ поспрашивать ,кто -то хвастался что делал приложение которое пользовалось этим протоколом .
Это расширение не прижилось из-за «атомарной» типа передачи данных самого X протокола ,сперва графические данные а затем в костыльной надстройке звук ,т.е возникали задержки .А 100 мб сетки тогда были редкость .

В иксах есть двойная буферизация на окно, в вэйланде нет.

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

Добавлю -нашел страничку с разговором про это расширение ,там и есть ссылка на оригинальный проект
[Археология] AUDIO - расширение протокола X11

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

В иксах есть двойная буферизация на окно, в вэйланде нет.

Ахинея. Определись с терминами и их значением, потом берись философствовать.

И что тебя забавляет? Нужность 2д ускорения для иксов - недостаток.

Совет почитать про макось прошел мимо.

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

«Услышал знакомое слово, но не понял, что оно значит?» (c)

Рассмотрим ситуауцию без композитного менеджера.

Мой косяк, всё сказанное выше действительно для работы при композитном менеджере.

Без него приложение «владеет» областью в front buffer (непосредственно отображаемый буфер) X'ов. При перекрытии окна другими окнами, перекрываемая область откусывается от окна и занимается другим приложением. Когда окно отодвигается, X'ы посылают приложению событие перерисовки и заполняют область каким-то цветом. Дальше ждут когда приложение перерисует облать.

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

Если есть композитный менеджер, то окно перенаправляется в отдельный буфер, который уже отрисовывается как надо композитором. События перерисовки оно, я так понял, при этом всё равно получает, но тут не уверен.

Быстрогугл на эту тему ничего не дал, сам я не в курсе, возможно пропустил.

0000000000

devzero он такой, байтики текут, а информации по делу 0.

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

Да, в большинстве случаев это так. Но в некоторых - не так. Например, в случае с вышеупомянутым gnustep. И почему это не так, я нигде не нашел ответа.

Возможно он устанавливает background-pixmap, тогда иксы при «раскрытии» сами будут заполнять окно тем, что передано в этом pixmap'е, а потом ждать перерисовки.