Готовый перевод The Wayland Situation: Facts About X vs. Wayland / Факты о состоянии X и Wayland: The Failings of X

Внимание! Этот перевод, возможно, ещё не готов, так как модераторы установили для него статус «идёт перевод»

То, что поломано в X

С точки зрения автора, преимущества и особенности Wayland лучше всего рассмотреть со стороны недостатков X.

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

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

B) Теоретический пример: Rekonq поддерживает Xinput 2.2. Kdelibs поддерживают Xinput 2.0, Флэш-плагин поддерживает Core X11, и все эти компоненты будут бороться за ту версию, которую поддерживает Rekonq, и в конце концов вы получите версию, которую поддерживают все, причем эту версию не обязательно будут поддерживать АБСОЛЮТНО ВСЕ приложения.

C) Если вам повезло, вы получите минимальную поддерживаемую версию и все будет работать. Если не повезло, то будет задействована максимальная версия, и вы будете передавать бесполезную, потенциально могущую вызвать ошибки информацию между клиентом и X-сервером.

II) X поддерживает четыре подсистемы ввода: Core X11, Xinput 1.0, Xinput 2.0 и Xinput 2.2. Xinput 1.0 устарел и не используется, но оставшиеся три в большей степени зависимы друг от друга, чем независимы. По словам Дэниэла Стоуна, "Есть только три человека, кто действительно понимает, как подсистемы ввода взаимодействуют друг с другом, и я хотел бы не быть одним из них."

III) Много лет назад, у кого-то появилась идея "Механизм, но не способ." Что это означает? То, что X имеет свой собственный X-специфичный API отрисовки, свой собственный тулкит наподобие GTK+ или Qt. Он определяет такие низкоуровневые вещи, как отрисовка линий, дуг, окружностей, простейших шрифтов и других "строительных" компонентов, которые бесполезны сами по себе. Примечание от Дэниэла: "Широкие линии должны отрисовываться с точностью до пикселя по спецификации, что в результате делает их выглядящими уродливо."

IV) X-сервер огромен. До того, как комьюнити взялось за работу над ним и начало выкидывать отдельные его части, он был почти что целой OS.

A) Например, X-сервер имел свой собственный сервер печати. Он был отделен после того, как кому-то пришлось добавлять поддержку Xprint в glxgears (не уверен в точности перевода данной фразы - прим. пер.)

B) Он имел в комплекте бинарный интерпретатор форматов ELF, COFF и a.out.

V) Композитинг и согласование окон. Разработчики научили X композитингу через расширение Composite. Для простых вещей, таких как десктоп и GL, оно работает хорошо. Если же вы хотите использовать аппаратные оверлеи (для видео), все становится просто ужасным.

A) Согласование медиа. Что такое согласование медиа? К примеру, есть браузер с открытой страничкой Youtube. Это окно. Флэш-плеер, проигрывающий видео, это суб-окно. Кто занимается их синхронизацией? Никто. События обрабатываются данными окнами раздельно, и в нынешней ситуации остается только молиться, чтобы обработка событий не разошлась слишком сильно друг от друга. Поэтому, когда вы проматываете страницу с встроенным видео, все дергается и рвется.

VI) Шрифты. Разработчики пытались научить X-сервер работать со шрифтами через расширение STSF. Идея заключалась в том, чтобы отрисовывать шрифты на сервере и раздавать клиентам достаточно информации для того, чтобы они могли правильно определить наложение шрифтов на их окна. Количество информации, достаточной для выполнения даной задачи, превышало размер самих шрифтов. Так что в конце концов было решено просто отдавать шрифты клиентами и позволить им самим работать с ними.

VII) Statelessness... Другими словами - X ничего не запоминает.

A) "Пожалуйста, сгенерируй мне конфиг файл." В конечном счете исправлено тем, что X-сервер использует конфиг-файл только для переопределения и имеет адекватные параметры по умолчанию и использует автоопределение.

B) Кто не имел проблем с мультимониторной конфигурацией под Linux? Или не настраивал все заново после перезагрузки? X сбрасывает все настройки, и только если вы прописали их в /etc/X11/xorg.conf.d/50-monitors.conf, они будут запомнены. Однако вам скорее всего все придется писать руками.

C) Это, возможно, будет исправлено созданием libkscreen, враппером для xrandr, который запоминает конфигурацию мониторов по их уникальным EDID.

D) В течение долгого времени, возможно даже до сих пор, была возможна ситуация, когда при подключении дополнительного монитора на основном мониторе работал композитинг, а на дополнительном нет. Это ВОЗМОЖНО исправлено RandR1.4, однако автор не нашел единогласного да или нет по этому вопросу.

VIII) Иерархия окон - это полный беспорядок. В X каждый элемент ввода и текстовое поле были отдельными окнами, которыми владело родительское окно. По этой причине никто не понимает функию, проверяющую дерево окон. Реальные тулкиты (не Core X11) не делают так уже давно.

IX) Хоть это и придирки, но все же заслуживает внимания. В X11, глобальный счетчик пикселей имеет размер 15 бит. Что означает, что на всех ваших дисплеях суммарно не может быть больше 32 768 пикселей. Для 100dpi это соответствует дисплею диагональю 8.3 метра. Windows XP поддерживает 95dpi. У телефонов сейчас больше 320dpi. А если учитывать большие разрешения и мультимониторные конфигурации, то ситуация станет рискованной уже очень скоро.

X) Для X все является окнами. Не существует различных типов окон, это просто "окна".

A) Скринсейвер? Это окно, которое говорит X:
1) Размести меня поверх всех окон
2) Сделай меня полноэкранным
3) Отдай мне весь ввод

B) Всплывающее окно? Это окно, которое говорит X:
1) Помести меня в эту позицию
2) Отдай мне весь ввод

C) В чем проблема? Скринсейвер не активируется, пока активно всплывающее окно, так как они конфликтуют друг с другом.

D) Ваш скринсейвер и скринлокер, возможно, не умеют обрабатывать медиа клавиши, забирая при этом весь ввод. Пример: вы работаете дома, слушая музыку, собираетесь уходить, захлопываете крышку ноутбука. Ноутбук засыпает, оно скринсейвера является активным. Как только вы открываете крышку, музыка возобновляется, и легче просто снова захлопнуть ноутбук и разобраться с этим позже, чем ввести пароль, добраться до медиаплеера и приостновить его или ткнуть Mute. (имхо ССЗБ, но тем не менее - прим. пер.)

E) Разработчики пробовали исправить это. Они спроектировали расширение, проработали теорию. Однако когда пришло время реализовать все это, они осознали, что необходимые изменения слишком сильно сломают модель функционирования X. Так что этот дефект является не исправленным в течение 26лет и не похоже, что ситуация улучшится.

XI) "Если X11 такой ужастный, почему бы не сделать X12 вместо создания совершенно нового протокола?" Частично это было сделано: http://www.x.org/wiki/Development/X12

Проблема с тем, чтобы развивать замену X11 под именем "X" в том, что те, кто заинтересован в X, будут иметь право голоса и в будущих версиях X. Если называть нововведения "Wayland", то этой проблемы нет. Это независимый проект, и его разработчики могут делать с будущим дисплейным сервером что хотят, не оглядываясь на требования тех, кто заинтересован в X. Те же, кто заинтересован именно в "X", могут участвовать в разработке X12.

Внимание! Этот перевод, возможно, ещё не готов.
Его статус: идёт перевод

Переведено на Нотабеноиде
http://notabenoid.org/book/41077/155424

Переводчики: kravich

Настройки

Готово:

100.00% КП = 1.0