LINUX.ORG.RU

Ситуация с Wayland: факты о X и Wayland.

 ,


32

7

Это вольный перевод статьи, намедни размещённой на phoronix. Оринальная статья — обзор недостатков, их исправлений и преимуществ между X и Wayland. Её написал Eric Griffith, при участии Daniel Stone, специально для ресурса phoronix. Работа собрана по кусочкам из презентаций Keith Packard, David Airlie, Kristian Høgsberg, из страниц про X11, X12, Wayland в вики и на freedesktop.org, из прямых интервью с разработчиками.

Оригинал выпущен под Creative Commons версия 3, с указанием авторства; перевод доступен на тех же условиях (с указанием на авторов оригинала, как мне кажется).

Недостатки X

Прежде всего автор думает, что преимущества Wayland лучше всего понятны через перспективу недостатков X11. Итак, начнём...

  1. Мы потратили последние десять лет на «исправление» X с помощью оборачивания его расширениями и плагинами. Однако, X имеет минимальную поддержку версионирования расширений.
    • Версионирование ведётся для одного клиента, а не для одного соединения с API расширения; если ваше приложение поддерживает одну версию расширения, а библиотеки — другую, вы не можете предсказать, какая версия расширения будет получена в итоге.
    • Мысленный эксперимент: Rekonq поддерживает Xinput 2.2, библиотеки KDE — Xinput 2.0, а плагин Flash — только базовый X11. Все они будут определять, какая версия подсистемы ввода поддерживается браузером Rekonq, и в результате будет отдана одна версия для работы со всем вводом... И это может быть не та версия, которая имеет всё необходимое.
    • Если вы счастливчик, вы получите минимальную поддерживаемую версию и приложение будет работать хорошо. Если вы не очень удачливый, вы получите максимальную версию и будете посылать бесполезные сообщения между клиентом и X.
  2. X имеет четыре подсистемы ввода: базовый протокол X11, Xinput 1.0, Xinput 2.0, Xinput 2.2. Xinput 1.0 канул в Лету, но оставшиеся три остаются взаимосвязанными. Daniel Stone описал это так: «Есть всего три человека, которые действительно понимают, как подсистемы ввода уживаются вместе... И я бы хотел не быть одним из них».
  3. Много лет назад у кого-то появилась идея «механизм, а не алгоритм». Фраза является отсылкой к тому, что X имеет свой уникальный API для рисования и собственную библиотеку вроде GTK+ или Qt. X определяет низкоуровневые понятия, такие как прямая линия, толстая прямая линия, дуга, окружность, неполноценные шрифты и другие элементы конструктора, бесполезные по отдельности. Примечание от Daniel: «Внешний вид толстых линий должен точно соответствовать спецификации, которая обязывает их выглядеть уродливо».
  4. X большой и тупой. Прежде чем мы (сообщество) начали выкидывать его компоненты и использовать обходные пути, X имел внутри почти полную ОС, включая свой сервер печати и свой бинарный транслятор для ELF, COFF и a.out.
  5. Композитинг и синхронизация окон. Разработчики научили X композитингу с помощью Composite Extension. Композитинг хорош для простых случаев, как то: рабочий стол, OpenGL. Но если вы захотите использовать hardware overlays (т.е видео), может случиться катастрофа. В том же браузере содержимое вкладки и окно flash-плагина обрабатываются отдельно и не синхронизируются, так что остаётся лишь скрестить пальцы в надежде. что разница во времени обработки не будет слишком большой. В результате при прокрутке страницы с играющим видео иногда возникают разрывы и артефакты.
  6. Шрифты. Разработчики пытались перенести шрифты под управление X-сервера с помощью расширения STSF, и предоставить клиентам достаточную информацию, чтобы те могли правильно определить расположение шрифтов на экране. Но количество информации, достаточной для выполнения данной задачи, превышало размер самих шрифтов. В итоге было решено предоставить клиентам полную свободу действий, избавившись от шрифтов на сервере.
  7. Протокол без состояний. Иными словами, X ничего не запоминает.
    • «Пожалуйста, создайте мне X.conf. Пожалуйста, используйте его для настройки.» Зачем?! Со временем это было исправлено: файл конфигурации используется для перезаписи параметров по умолчанию, а сами параметры по умолчанию подчищены и могут теперь определяться автоматически.
    • Многие имели проблемы с многомониторными конфигурациями в Linux, ну или хотя бы перенастраивали X после перезагрузки. Недостаток X в том, что он помнит эти конфигурации только после создания /etc/X11/xorg.conf.d/50-monitors.conf, который скорее всего придётся писать вручную.
    • Мы надеемся, что это было исправлено созданием libkscreen, обёртки над xrandr, которая наконец-то стала запоминать параметры мониторов, используя их уникальный EDID.
    • В течение длительного периода (а может быть и до сих пор) при подключении дополнительного монитора в Linux основной монитор имел композитинг, а дополнительный — нет. Это, возможно, исправлено в RandR1.4, но его автор не может найти убедительных доказательств.
  8. Бесполезная иерархия окон. В X каждое поле ввода и текстовая надпись имеют своё окно со своим родителем. Никто не знает, какую же функцию выполняет эта иерархия. Реальные библиотеки (т.е не основанные на компонентах протокола X11) уже давно выбросили весь этот мусор в окно.
  9. Отчасти придирка, отчасти разумное беспокойство... В X11 каждая из координат— 2-байтное число со знаком. То есть, на всех ваших дисплеях должно быть не более 32,768 пикселей. При 100dpi это даёт вам 8,3-метровый дисплей. Замечательно... Но вот факты для сравнения: Windows XP имеет 96 DPI, а мой телефон — 320+. Добавьте сюда растущие разрешения и несколько мониторов, и вы увидите, что проблема приближается очень даже быстро.
  10. Для X всё является окном, и разных типов окон с его точки зрения нет.
    • Скринсейвер — это окно, которое просит X расположить его поверх всех окон, сделать полноэкранным и отдать весь ввод.
    • Всплывающее окно просит X расположить его в заданной точке и отдать весь ввод.
    • Они конфликтуют: скринсейвер не будет активирован, пока показано всплывающее окно.
    • Наверняка ваши скринсейвер и скринлокер не прокинули хуки во все необходимые библиотеки, распознающие клавиши для управления медиа... Представьте, что вы слушали музыку, работая на ноутбуке, а затем закрыли крышку. Ноутбук уснул, скринсейвер стал активным окном. Как только вы откроете крышку, ноутбук проснётся и музыка загромыхает снова, так что снова закрыть крышку окажется проще, чем вбить проль, затем открыть плеер и поставить его на паузу либо выключить звук.
    • Разработчики пытались исправить проблему и сделали спецификацию нового расширения, которое в теории работало. Но когда его попытались реализовать, оказалось, что оно серьёзно ломает модель работы X-сервера. Так что проблема существовала 26 лет и продолжает существовать. Расслабьтесь и получайте удовольствие.
  11. «Но Eric, если X11 настолько плох, то почему бы не сделать X12 вместо нового протокола?». Ну, формально, это уже сделано. При сохранении его под знаменем X возникает практический недостаток: все, кто беспокоится о X, будут иметь право голоса в разработке следующей версии. С помощью названия «Wayland» этой проблемы можно избежать. Никого ничто не волнует. Это не связанный с X проект, разработчики могут творить с будущим дисплейным сервером всё, что душа пожелает, ну а те, кто беспокоится о X, могут пойти разрабатывать X12.

Лекарство от Wayland (пронумерованы попарно с недостатками X).

  1. Весь протокол версионирован. Каждый слушатель получает именно ту версию, которую он поддерживает, и ничего поверх этого. Никаких случайностей.
  2. Подсистема ввода в Wayland очень похожа на Xinput 2.2, за вычетом всего старья и отношения Master/Slave между источниками ввода. Слушатель получит одну виртуальную клавиатуру, одну виртуальную мышь и один невиртуальный сенсорный ввод. Кошмар под названием «мультитач» в конце концов упорядочен. Примечание от Daniel: как один из авторов мультитача в X, я считаю себя достаточно компетентным, чтобы назвать его кошмарным.
  3. У Wayland нет API для рисования, в обход которого можно было бы работать. Wayland ожидает заполнения клиентом буфера рисования, и его не волнует способ заполнения, если не считать контроля за попытками задеть чужие буфера.
  4. Wayland минималистичен, он не хранит внутри себя псевдо-ОС ради контроля вывода графики. Клиенты принимают на себя этот удар, что хорошо — им не придётся заботиться о сверхдолгом сопровождении обратной совместимости. Qt5 избавилось от модуля qt3support. X всё ещё сопровождает то, что было написано 26 лет назад. Примечание от Daniel: кроме того, вызовы к вейланду — не блокирующие, рисование всего рабочего стола не остановится из-за зависания или очень дорогой операции на стороне одного из клиентов: остановится только этот клиент.
  5. В вейланде — принудительный композитинг. Это не означает, что везде должны быть 3D-эффекты или изгибающиеся окна. Под композитингом мы подразумеваем отсутствие разрывов, необновлённых кусков и проблесков. Лозунг вейланда — «каждый кадр будет идеальным». Каждый пиксель прорисован как должно и расположен где должно, и появляется, когда клиент того потребует.
  6. Шрифты отданы клиентам.
  7. Многомониторные конфигурации и гибридная графика (Optimus) отданы клиентам, вейланду нужен только буфер с пикселями и информация о том, где его расположить.
  8. В вейланде есть два вида окон: окна верхнего уровня и подповерхности (в основном для проигрывания видео). Причём, в отличие от X, они синхронизируются. При прокрутке страницы с видео в браузере у вас не будет ни разрывов, ни артефактов.
  9. С точки зрения клиентов, вейланд не оперирует глобальными координатами, предпочитая систему отсчёта поверхности для рисования. Счётчик координат 31-битный, то есть каждая поверхность может иметь 2,147,483,648 пикселей как в ширину, так и в высоту.
  10. Для обеспечения дополнительной безопасности, ваш скринсейвер и скринлокер являются частью композитора. Кроме того, композитор распознает клавиши управления медиа, так что даже при заблокированном экране можно выключить звук.

Некоторые заблуждения в плане X и Wayland.

  1. «X — это юниксвейно». X обрабатывает печать, управление буферами для рисования, имел свой тулкит, обрабатывал шрифты, имел бинарный транслятор — и всё это помимо других задач.
  2. «В X есть сетевая прозрачность» — её нет. Базовый протокол X и DRI-1 имели сетевую прозрачность, но никто не использует ни то, ни другое. Shared-memory, DRI2 и DRI-3000 не имеют сетевой прозрачности и не работают по сети. В наше время X превратился в синхронный, плохо сделанный VNC. Если бы он был плохо сделанным асинхронным VNC, то может быть мы бы и заставили его работать. Но он не такой: XLib синхронная, а переход на XCB медленный, что делает передачу по сети настоящим кошмаром.
  3. «Разработчики Wayland наступают на те же грабли, что и X11, потому что не знают его» — неверно, потому что большинство разработчиков Wayland являются бывшими разработчиками X11.
  4. «Вейланд требует 3D.» — неверно, он требует только композитинга, так что есть даже бекенд на pixman для программной отрисовки.
  5. «Вейланд не умеет в удалённый доступ» — умеет, и должен справиться с этой задачей лучше чем X, отчасти из-за асинхронности протокола. Скорее всего Wayland станет высокопроизводительной версией VNC, и прототип уже есть. Причём мы ещё ни разу не давали идей по его улучшению, и скорее всего сможем сделать его лучше, если приложим усилия.
  6. «Вейланд нарушает обратную совместимость» — с тех пор как XWayland закончен и принят в основную ветку, у нас должна появиться почти совершенная обратная совместимость, потому что каждое приложение, использующее X, получает маленький X-сервер для дальнейшей работы с ним. Нам известно одно препятствие — трансформации окна, ведь приложение думает, что оно расположено в верхнем правом углу экрана, оттого, что клиентский X-сервер приведён к размерам клиентского окна.

Парочка характерных преимуществ Wayland

  1. «Каждый кадр будет идеальным». Каждый кадр будет представлен в правильном порядке (возможен сброс лишних кадров, но вы не получите кадр 199, затем 205, а затем 200 оттого, что сервер извлёк их в произвольном порядке. Каждый кадр имеет свой timestamp.)
  2. Минималистичный! Мы способствуем славному будущему Wayland путём уменьшения пространства для возможных ошибок.
  3. Бекенды, специфичные для оборудования. Думается, некоторые люди заметили появление бекенда Wayland, предназначенного для Rasberry Pi — он позволяет использовать все особенности этой платформы. Такой подход используется не везде, многие вещи не потребуют бекенда для конкретного оборудования, но неплохо бы иметь возможность сделать доработку, когда потребуется.

P.S. От переводчика: заметно, что в статье мало технических деталей или же ссылок, а лозунги я наоборот вырезал. К слову, о минималистичности: для вейланда уже есть композитор, способный отображать окна в 3d-пространстве на манер quake, но что-то я сомневаюсь в правильной обработке звука в таком 3d. Для игр есть OpenAL, который имеет 3d-координаты, соответствующие координатам OpenGL (синхронизация позиций источников звука и слушателя с позициями объектов и камеры производится программистом). Для вейланда нет ничего подобного OpenAL.

Если же кто-то имеет вопросы к авторам статьи — он может задать их на Phoronix.

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

★★★★

Проверено: maxcom ()
Последнее исправление: Aceler (всего исправлений: 16)

Когда уже можно будет его использовать? И интересно подобное описание Mir.

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

и еще вопрос знатокам: если он такая няшка (и во много раз проще X`ов) почему за столько лет его демки не продвинулись дальше демки Mir`а? А в демке Mir`а все очень даже ничего. И это при том что миру менее года..

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

Очень хочется сделать так, чтобы Wayland не устаревал ещё лет 20, я думаю.
Поправка: не менее года, а менее года публично.

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

Ну, при демонстрации Mir показывалась не абстрактная демка, а вполне конкретная Unity Next. Точно также в wayland работает XWayland, обеспечивающий совместимость с иксами, большая часть софта на Qt и GTK3, специально портированные приложения. Вполне, по моему, равноценная ситуация, а если учитывать, что еще не показывали софт на qt и gtk, запущенный под Mir, то...

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

1. Мир пилят уже довольно давно. Сообществу сообщили о нем недавно.

2. Вейлендом первое и довольно продолжительное время занималась пара человек. Много времени потратили на ресерч.

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

4. Сам по себе Мир практически ничего еще не умеет. К Вейленду уже вовсю прикручивают плюшки.

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

К Вейленду уже вовсю прикручивают плюшки.

Плюсую. Достаточно почитать их мейлинг-лист. Из недавнего: поддержка цветовых профилей и colord, поддержка скейлинга под различные dpi(sic!), обеспечение взаимодействия с systemd, реализация мультисит.

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

Сам по себе Мир практически ничего еще не умеет. К Вейленду уже вовсю прикручивают плюшки.

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

Qt platform abstraction позволяет портировать весь фреймворк на новый дисплейный сервер с минимальными усилиями, даже haiku этим смогла воспользоваться, а API/ABI фреймворка не меняются. Благодаря этому у разработчиков Mir нет необходимости в стабильном протоколе и аккуратном продумывании расширений к нему.

quiet_readonly ★★★★
() автор топика
Последнее исправление: quiet_readonly (всего исправлений: 1)
Ответ на: комментарий от ZuBB

Мир пилят уже довольно давно

В новостях было. Сначала долго изучали Вейленд, потом решили запилить свой. Начали где-то весной-летом 2012.

программистов над ним работающих изначально больше

Конкретную ссылку не вспомню, где-то в обсуждениях на Форониксе.

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

у тебя перевод лучше, поэтому свою удалил

Тем не менее спасибо — я повытягивал некоторые фразы из вашего перевода ;)

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

> Мир пилят уже довольно давно

В новостях было. Сначала долго изучали Вейленд, потом решили запилить свой. Начали где-то весной-летом 2012.

И это при том что миру менее года..

а ну тогда это точно долго.

ZuBB ★★★★★
()

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

Однако пока Wayland, увы, не готов. Надеюсь, что это изменится.

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

и тем не менее обоим авторам большое спасибо

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

а ну тогда это точно долго.

Не надо выдирать слова из остального контекста. Где сейчас Вейленд и где Мир, ага. Последний вообще только на Ютубе можно посмотреть.

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

А если заглянуть на wiki, то можно увидеть и пакеты на ppa, а также инструкцию по включению Мира.

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

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

И это при том что миру менее года..

/*обьясню*/ ИМО за год мир продвинулся дальше нежели вейданд за 5-летку

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

ИМО за год мир продвинулся дальше нежели вейданд за 5-летку

Я тоже объяснил, почему так.

anonymous
()

А теперь минусы и плюсы вяленда как обратная сторона медали:

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

А что нового? А нового - это значит в каждый композитор надо будет перенести велосипеды xlock и xscreensaver. Чуваки жгут не по детски.

Хотя, на фоне следующего пункта, этот пункт выглядит совершенно невинно. В чём же заключается этот новый пункт с адским отжигом? А вот в чём: «с тех пор как XWayland закончен и принят в основную ветку, у нас должна появиться почти совершенная обратная совместимость, потому что каждое приложение, использующее X, получает маленький X-сервер для дальнейшей работы с ним. Нам известно одно препятствие — трансформации окна, ведь приложение думает, что оно расположено в верхнем правом углу экрана, оттого, что клиентский X-сервер приведён к размерам клиентского окна.». Вместо того, чтобы тупо реализовать rootless X сервер, они предпочли для каждого приложения создавать собственный рутабельный (в смысле с root-окном) X-сервер, и внутри него рендерить X-клиента... Если честно, мне страшно подумать как они будут реализовывать открытие такого окна - при запуске X-клиента, для него стартует XWayland, в котором работает какой-нибудь XWaylandWM, который смотрит на размер окна показываемого X-клиента, содаёт для него виртуальный X-сервер, и рендерит на него окно. А значится изменение размеров такого окна X-клиента будет делаться не иначе как изменением разрешения этого X-сервера, с последующей отправкой через XRandr соответствующего события??? А как они выкрутятся из ситуации, когда у X-клиента более одного top-level окна???

Что-то с каждой «новастью» и каждым «орхитектурным ришением вэйлэнд (тм)» создаётся впечатление полной ублюдочности этого проекта:

1. Cетевую прозрачность - потеряли. Вообще. Даже ту убогую которая была

2. Независимость от дисплейного сервера - не приобрели (сдох вялендокомпозитор - все его клиенты сдохли)

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

4. Изобретение велосипедов с CSD (client-side-decoration) возвели в ранг абсолютного достоинства

5. Кроссплатформенность и способность работать в гетерогенной среде (естественное следствие «распределённости» X) - потеряли

Походу, пора сваливать на «девяточку максимальную на руктракере купленную».

no-dashi ★★★★★
()

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

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

К Вейленду уже вовсю прикручивают плюшки.

Плюсую. Достаточно почитать их мейлинг-лист. Из недавнего: поддержка цветовых профилей и colord, поддержка скейлинга под различные dpi(sic!), обеспечение взаимодействия с systemd, реализация мультисит.

а потом вдруг вспомнили, что у них переключалки раскладки клавы нет! и в спешке приклеили ее сбоку скотчем.

der_looser ★★
()
Ответ на: комментарий от no-dashi

Нужно просто расслабиться и получать удовольствие :D

carasin ★★★★★
()
Ответ на: комментарий от no-dashi

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

Это выглядит как паранойя, потому что пока что видно только обратное. Раньше процесс входа в систему управлялся разными *dm, сейчас эти функции берёт на себя systemd (даже в убунте) и lightdm. Раньше программы мусорили своими данными прямо в папку $HOME, сейчас всё чаще даже авторы движков вроде cocos2d-x кладут их куда полагается по спецификации. Раньше были свои IPC у KDE и GNOME, а также отсутствие оных в остальных DE, сейчас появился dbus и даже его поддержка в легковесных DE.

quiet_readonly ★★★★
() автор топика
Последнее исправление: quiet_readonly (всего исправлений: 1)
Ответ на: комментарий от no-dashi

1. Cетевую прозрачность - потеряли. Вообще. Даже ту убогую которая была

Вроде бы virtualgl никуда не выкинули, живёт, здравствует, используется в bumblebee.

5. Кроссплатформенность и способность работать в гетерогенной среде (естественное следствие «распределённости» X) - потеряли

Нет, не потеряли. На Mac OS X запускается совсем не тот X, что на линуксе (и пусть даже кодовая база одна). И вейланд можно будет там запустить, если кому-то понадобится.

quiet_readonly ★★★★
() автор топика
Последнее исправление: quiet_readonly (всего исправлений: 1)
Ответ на: комментарий от mos

попробую все ж
in no particular order:

1) на мой дилетантский взгляд, говоря о «проблемах» Х, они в основном указывают на недостатки реализации, а не архитектуры вообще. хотя и последнее присутствует, но в меньшей степени, тем более нет критики самой идеи Х. однако, что удивительного, что протокол иксов, которому десятки лет, реализован, мягко говоря, не идеально? та же многомониторность - тогда просто не было потребительских (или хоть каких-то) адаптеров с двумя выходами, xinerama заточена под неск. разных Х-серверов. ясно, что пришлось городить костыли. и так по многим пунктам.

интересно, их вяленд сколько протянет?

2) насчет «идеи иксов» - тут по-моему всё просто, достаточно взглянуть вокруг на конкурирующие продукты. Citrix имеет нехилый гешефт со своей ICA, некрософт вкладывается в RDP. Иксы же сделали всё это раньше, да и, наверное, изящнее в каких-то смыслах. тут же предлагается выкинуть идею, которая так «трендится» в мире и заменить на клон... coregraphics что ли?

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

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

5) про сетевую прозрачность - они говорят, что текущее поколение Х утратило сетевую прозрачность и приводят такой аргумент, что shm, DRI2, DRI3000 не прозрачны. только вот забывают упомянуть, что сделаны они таковыми изначально, тем же Keith Packard, и это как бы не «вина» иксов, что этим вещи сразу были сделаны наперекор изначальной идее. получается замкнутый круг - иксы прозрачны? нет. почему? потому что современная реализация отрисовки не прозрачна. а почему? потому что такой её сделали. и так по кругу. так же со всеми вещами, которые перекинули на сторону Х-клиентов.

6) иксы нынче гоняют картинки по сети и просто являются плохим VNC. крайне спорно. во-первых есть NX, была какая-то внутреиксовая примочка типа libxproxy, делавшая подобное же. может работать даже на плохих соединениях.
или вот я пробовал (в локалке) LTSP - экспириенс с VNC не сравним.
и опять же, превратился Х в гонялку картинок тоже не совсем по той причине, что оригинальная идея совсем уж плоха. надо «всего лишь» договориться об одном тулките уже современном и запихнуть в кору Х. нэ?
а вот вяленд, как я понимаю, просто предлагает встроенный VNC.

7) если идеи иксов осовременить должна получиться просто конфэтка - открытая мощная система граф. терминалов, c потенциальной возможностью перегонять граф. приложения с одного сервера на другой (это вроде уже даже реализовано на иксах в рамках проекта http://winswitch.org/ и штуки под названием xpra), вполне нормально работающая и на локалхосте (если уж иксы работают)

наверняка много всякой глупости выше понаписал, но эти мысли насчет Х уже давно как-то сформировались и данный «опросник» только подлил масла в огонь. буду благодарен если кто-то (даже кратко, тезисно) дезавуирует, или наоборот, подтвердит.

mos ★★☆☆☆
()

Многомониторные конфигурации и гибридная графика (Optimus) отданы клиентам

Не понял кто теперь будет заниматься многомониторными конфигурациями

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

Ну и самый важный вопрос, как в wayland будет сделана переключалка раскладки?

Как композитор решит. С дирижёром вместе.

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

Иксы же сделали всё это раньше, да и, наверное, изящнее в каких-то смыслах.

Люди, которые работали с графикой по сети не как пользователи, говорят что нет. Логика говорит что нет. А вы твердите, что изящнее ;)

Какое там изящнее? OpenGL по сети гоняется? Тулкиту сообщается, что надо приспособиться к передаче по сети? В GTK 3.x включается HTML5 бекенд?

Если нет — то какое изящество вы там нашли?

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

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

К этому добавлю, что Intel демонстрировал вариант Tizen для ноутбуков, причём как раз с GNOME 3 (модифицированным). И за Tizen взялись серьёзно — давеча довелось взглянуть на его API, и там внезапно оказались в меру удобные для C++-программиста обёртки над классическими системными API, такие как AudioDecoder/AudioEncoder с поддержкой Vorbis, Mp3, Flac и прочих принятых в линуксе форматов.

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

про сетевую прозрачность - они говорят, что текущее поколение Х утратило сетевую прозрачность и приводят такой аргумент, что shm, DRI2, DRI3000 не прозрачны. только вот забывают упомянуть, что сделаны они таковыми изначально, тем же Keith Packard, и это как бы не «вина» иксов, что этим вещи сразу были сделаны наперекор изначальной идее.

А вы готовы показать shared memory с сетевой прозрачностью?

quiet_readonly ★★★★
() автор топика
Последнее исправление: quiet_readonly (всего исправлений: 1)
Ответ на: комментарий от mos

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

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

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

изящество не в передаче тридэ рендеринга по сетке.

а вообще система рисования окошек - та же ICA приделана как-то к венде, неужели «изящнее»?

а насчет оpengl, действительно есть варианты - либо на сервере рендерить (тогда на клиенте можно обойтись без мощной видеокарты), а передавать видео (может закодированный?), либо всё-таки оффлоадить opengl на клиента, если много слишком видео гонять (как я понимаю, и такой вариант существует, только убог).

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

либо всё-таки оффлоадить opengl на клиента, если много слишком видео гонять (как я понимаю, и такой вариант существует, только убог).

Существует (virtual gl), только пользователь хотел бы, чтобы такие вещи разрешались автоматически в зависимости от возможностей тулкита и дисплейного сервера как на клиенте, так и на сервере.

Ну и на счёт видеокарты на клиенте — сейчас видеокарты на телефоне могут рисовать десктоп и гонять игры с неплохим разрешением, так что незачем держаться за старые представления о видеокартах в рассуждениях о новых тонких клиентах.

quiet_readonly ★★★★
() автор топика
Ответ на: комментарий от no-dashi

Независимость от дисплейного сервера - не приобрели (сдох вялендокомпозитор - все его клиенты сдохли)

Кстати, а почему, интересно? Это же такая нужная штука, которая уже сто лет просится в реализацию. Если делать всё с нуля, то почему бы и это не запилить?

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

А вы готовы показать shared memory с сетевой прозрачностью?

А вы готовы понять, что «shared memory» это тупиковое направление и прошлый век, поскольку рисовать надо примитивами?

no-dashi ★★★★★
()
Ответ на: комментарий от Axon

Кстати, а почему, интересно?

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

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

А вы готовы понять, что «shared memory» это тупиковое направление и прошлый век, поскольку рисовать надо примитивами?

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

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

Рисовать примитивами — это GDI, самый тормозной API для отрисовки графики из всех доступных в винде.

А какой самый быстрый? DirectDraw, DirectX и OpenGL? Ну-ну.

Если вам в вашем ПТУ не объяснили, что OpenGL и DirectX - это, вообще-то, тоже «рисование примитивами», и разница между GDI, GL и DirectX фактически только в типах параметров и названиях функций, то добро пожаловать в реальный мир. Здесь оно именно так.

no-dashi ★★★★★
()
Ответ на: комментарий от Axon

И что конкретно она за собой влечёт?

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

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

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

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