LINUX.ORG.RU

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

 ,


29

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.

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

Ответ на: комментарий от Aceler

Ты предлагаешь принести в жертву локальную отрисовку ради сетевой? Хомячки против.

хомячков никто не спрашивает.

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

хомячков никто не спрашивает.

Ради них как раз всё и делается. Ойтишнеги негодуэ.

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

«Тормоза иксов проявляются на длинных пингах, а не на узких каналах. Приложения с сервера на соседней улице работают куда лучше, чем с хостинга в США. Хотя ширина канала одна и та же» с vnc и rdp все еще хуже. хотя безусловно «кросплатформенные» поделия тормозят куда сильнее Xlib-ных или там motif/tk-шных.

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

«Это не «тормоза иксов», а «тормоза xlib».» скорее тормоза qt-gtk-gnome.

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

1. Тред осилил, а шапку - не осилил? Пилится разработчиками Xorg. Что же до пресловутых «костылей» - технообслуга с опухшим ЧСВ не понимают, что технически совершенное решение ради самого по себе технического совершенства, никому кроме нее не нужно.

3. Ядро уже написал, писатель-модернизатор? Или «потребляешь, что тебе перепало от корпораций»? А, ясно, твое постоянно повторяемое «возомнивших себя королями» - это проекция такая.

Если бы только не ваш конструктивный анализ изложенный в пункте №2 вашего комментария я бы подумал что вы типичное школобыдло возомнившее что его комментарии имеет значение.

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

Кто это сказал, что отсутствие одного события «сильно упрощает» тулкит?

Разработчики тулкитов, я строчки не считал.

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

Я ставлю смайлики.

Отрисовка на локальном видеоускорителе в плане требований к ПО ничем не отличается от отрисовки на удаленном видеоускорителе.

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

Разделение клиент-сервер должно проходить именно по линии рисующего API.

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

Хорошо это или плохо — второй вопрос, пока нет реальных реализаций вейленда, говорить рано.

Я это пишу: 1) чтобы повыпендриваться, 2) чтобы ты потроллил в ответ; 3) чтобы прийти к каким-то конструктивным выводам — как думаешь, какой вариант?

Ну учитывая, что смайлик ты не поставил, это или 2) или 3).

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

с vnc и rdp все еще хуже.

с VNC и RDP не работал, не знаю, Citrix с сервера в Канаде работал очень пристойно.

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

Про shared memory ты уже благополучно забыл?

Что «shared memory»? shared memory используется для передачи битмапов с клиента на сервер или обратно. Она используется, поэтому что это более эффективно, чем гонять эти же данные через unix-сокет. Это механизм оптимизации, а не особенность архитектуры.

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

Что я считаю? Какой подход? Ты вообще понимаешь мысль, которую я изложил? Могу повторить: Отрисовка на локальном видеоускорителе в плане требований к ПО ничем не отличается от отрисовки на удаленном видеоускорителе.

При чем тут shared memory? Как её наличие противоречит изложенному? Если тебе что-то не понятно, спрашивай.

Нет.

Что «нет»? Есть какие-то аргументы?

Ты можешь разделять клиент-сервер по линии вывода буфера на экран.

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

Ты же сам ругался на вейланд, что там декорации рисуются на клиентской стороне — т.е. разделение находится в другом месте.

Какое отношение рисование декораций имеет к обсуждаемому?

Хорошо это или плохо — второй вопрос, пока нет реальных реализаций вейленда, говорить рано.

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

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

«Это не «тормоза иксов», а «тормоза xlib».» скорее тормоза qt-gtk-gnome.

O_o

o_O

Ты вообще в курсе, на что он отвечал? Откуда там qt/gtk/gnome?

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

так и иксменов никто не спрашивает. пусть себе воют

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

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

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

Что «нет»? Есть какие-то аргументы?

Я ж там и привёл аргументы, что в вейланде сделано по-другому и никто никому ничего не должен.

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

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

Ты почему-то сосредоточился на одной задаче графического сервера — сетевой. И в упор не видишь всего остального. Поэтому единственное что я могу предложить — дождаться реализации и пощупать преимущества своими руками.

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

так и иксменов никто не спрашивает. пусть себе воют

да.

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

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

Я отвечаю на реплику:

Ты предлагаешь принести в жертву локальную отрисовку ради сетевой?

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

Тот же OGL является полностью network-agnostic. Когда приложение получает контекст OGL и начинает отправлять ему команды, оно понятия не имеет, что это за сущность такая и где она находится. И не имеет никакой возможности это узнать.

Всё, что происходит, когда ты в приложении вызываешь, например, glBindTexture, лежит полностью на совести реализации.

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

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

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

Я ж там и привёл аргументы, что в вейланде сделано по-другому и никто никому ничего не должен.

Тут стоило бы уточнить, что такое «аргумент». Потому что фраза, на которую ты ответил «нет», была: «Разделение клиент-сервер должно проходить именно по линии рисующего API» в том смысле, что это наиболее эффективный способ. И наличие вейланда никак не служит аргументом в пользу того, что указанный способ не самый эффективный.

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

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

Ты почему-то сосредоточился на одной задаче графического сервера — сетевой. И в упор не видишь всего остального. Поэтому единственное что я могу предложить — дождаться реализации и пощупать преимущества своими руками.

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

Во-вторых. Я сосредотачиваюсь не на поддержке сети, а на грамотной архитектуре современного графического стека, который может обеспечить гибкость и расширяемость в будущем. Разные уровни абстракции должны быть развязаны друг с другом - это аксиома. Возможность сетевого рендеринга всего лишь лакмусовая бумажка: если уж даже от того, что уже 30 лет существует, архитектура не позволяет абстрагироваться, то как она будет абстрагироваться от новых условий, которые возникнут в будущем? Методом порождения костылей и костылей на костылях?

Подход «мы тут композитим битмапы, а откуда они берутся нам пофиг» — это тупиковый путь. Это взятие за основу архитектуры какой-то второстепенной детали реализации. Всё равно что проектировать здание правительства исходя только из того, как удобнее было бы в нём уборщицам мыть полы.

Это не серверу должно быть пофиг. Это как раз клиенту на всё должно быть пофиг. Для клиента должно быть стабильное рисовательное API. А каким раком встанет сервер, это уже детали реализации.

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

Какое отношение рисование декораций имеет к обсуждаемому?

Ну только показывает неадекватность Aceler'а, которому уже много народу твердит про недостатки Client-Side-Decorations. Эти самые декорации разрушают идею оконного менеджера: достаточно представить Xmonad с Qtшными декорациям, рассчитанными на Kwin (или наоборот - декорации Xmonad в Kwin).

При этом клиентские декорации ничего полезного не дают - xmms/chromium/gkrellm и другие «выпендрёжники» появились в незапамятные времена в X'ах. И прекрасно себя там чувствуют.

Aceler этой банальности не видит => дискуссии с ним - это метание бисера. Мне, лично, это давно надоело.

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

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

То, что вы пишете, это для Aceler'а «многа буков». Он не поймёт.

То, что OpenGL - это просто ещё один из протоколов рисования для Х, менее удобный, нежели core, но значительно лучше поддерживаемый железом, нежели другие, скажем PostScript, для него непонятно.

А ведь теперешнее железо значительно лучше подходит к идеологии Х, нежели раньше. Видеокарты сейчас прекрасно перемалывают векторные команды - OpenGL. Это в 86-м они только bitmap'ы жрали. :-)

Поэтому битмапный Wayland в 2013-м году - это чушь какая-то. Пацаны на 30-ть лет опоздали с инновациями.

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

ага, поэтому изобрели еще один протокол с пока что одной реализацией :)

- у нас четыре несовместимых протокола! Надо что-то делать - давайте разработаем обобщенный универсальный протокол! .... - у нас пять несовместимых протоколов!

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

Разработчики тулкитов, я строчки не считал

мм. это «событие перерисовки области» есть и в шиндовшс.

с чем боремся-то?

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

Если игнорировать все достоинства вейланда

ммм. Достоинства? Ты пошутил? Оно 1. не работает. 2. ломает то, что уже работает.

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

anonymous> xorg оный юниксвей нарушает аж бегом.

Не нарушает: есть сервер, есть клиент. Целое состоит из отдельных компонентов, которые выполняют свои задачи и выполняют их хороши. Всё по UNIX-Way.

Слишком толсто, осиль хотя бы unix haters handbook, раздел по иксам.

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

Нет никаких архитектурных проблем сделать реализацию X-сервера для работы с гибридной графикой.

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

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

я, в общем-то, там ( Wayland запущен без прослойки X.Org (комментарий) ) рассказал все, что знаю, а пейпер еще на зарюхал

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

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

кстати, вовсе не факт, что в Qt over X будут гонки, даже если Qt кидает целиком битмапы — я бы на месте авторов Qt как-нить извернулся, скажем, имел бы на окне аппликухи несколько виджетов, и кидал бы каждый новый битмап в *новый* виджет (по кругу), а старый бы уменьшал или менял ему z-order или че-то в этом духе

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

так что логика вейланда «давайте мы насрем в штаны и будем терпеть races, т.к. вася насрал в штаны и петя тоже» может быть неверна еще и в части васи и пети :-)

www_linux_org_ru ★★★★★ ()
Последнее исправление: www_linux_org_ru (всего исправлений: 4)
Ответ на: комментарий от vtVitus

В Исках был принт сервер и шрифты именно для данной ситуации. Но пришли инноваторы, которые выкинули ненужное ибо «нет людей, которые понимают, как это работает», «все глючит и сложно», «это никому не надо» и т.п. ни чего не напоминает?

Не знаю насчёт принт-сервера (хотя подозреваю, что альтернативы просто были на голову выше), но иксовые шрифты — ад. Их никто не выкидывал, но здравомыслящие девелоперы потенциально интернационализируемого приложения НИКОГДА не будут их использовать хотя бы потому, что на дворе не 1998 год, а 2013 и юникод неслабо так разбух, в протокол X11 в секции core fonts ему не влезть. Не считая того, что в шрифтах давно есть лигатуры, контекстно-зависимые глифы, локалезависимые глифы (самое веселье в том, что одна и та же софтина одним и тем же шрифтом из одного и того же codepointа в двух местах может нарисовать 2 разных глифа) и сама идея гонять отрендеренный битмап строки композитору и обратно в иксы, попутно сообщая клиенту каждый параметр этой строки — дикость. Ну и браузеры по определению будут игнорировать любые сервер-сайд шрифты, то же самое с любым издательским пакетом, серьёзным графическим редактором, да хотя бы и текстовым процессором и читалкой.

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

Можно 4 байта использовать в XCB, libX11 все равно уже давно лишь обертка над libxcb, так что в libX11 преобразовывать 4 байта в 2 и так отдавать клиентам. Заодно подстегнет переход на XCB.

Ты ничерта не разбираешься в вопросе. Ограничение в 2 байта — в протоколе X11. Не в библиотеке. Сервер по ту сторону протокола не обязан знать, что у тебя там за хаки в клиентских библиотеках.

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

у древнего Motif восемьсотмохнадцатого года выпуска с DPI проблем почти нет

Наверно, это единственное место, где у него почти нет проблем.

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

Насчёт гонок - в протоле иксов есть такое понятие как Sequence number. Если событие сгенерировано сервером раньше, чем до него дошел тот реквест, после которого кнопку можно считать видимой, тулкит эту ситуацию может отловить. Другое дело, реально ли разрабы тулкитов делают эти проверки, или же как всегда. Что-то мне кажется, что «как всегда».

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

Со шрифтами есть проблема.

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

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

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

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

но во всяком случае это снимает претензии к Х-ам и переносит их к тулкиту, и разрабы тулкита в принципе могут ситуацию исправить

если в вейланде сделают свой Sequence number, то я могу пересмотреть свое отношение к протоколу

однако мое отношение к Великим Архитекторам Вейланда, видимо, останется прежним

www_linux_org_ru ★★★★★ ()
Последнее исправление: www_linux_org_ru (всего исправлений: 2)
Ответ на: комментарий от der_looser

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

Ну да, в иксах лучше: сделали переключалку на 4 раскладки, сказали в доках: «хотите раскладки — включайте на клиентской стороне» (некоторые девелоперы до сих пор не включают, ну а что, это механизм, а не политика). Поняли, что четырёх раскладок мало, добавили XCompose и XIM, объясняя в ICCCM: «хотите по-настоящему уметь раскладки — включите ещё и это на клиентской стороне» (опять же, объясни каждому, что для клавиатурного ввода нужно ещё и пропускать все события через это, и объясняй им политику впридачу к механизму). Девелоперы тулкитов поняли, что оба варианта — говно мамонта и запилили ещё и GTK_IM_MODULE и QT_IM_MODULE, которые, к счастью, руками включать не надо. Иксы тут, впрочем, уже не участвуют. Вообще. Но все эти механизмы до сих пор работают перпендикулярно основным четырём иксовым раскладкам и мы можем наслаждаться вводом широких пробелов и знаков препинания с включенной русской иксовой раскладкой (такой дикости даже в win95 не было). Сейчас девелоперы DE начинают понимать всю ситуацию и переползать на внеиксовые механизмы. К счастью, девелоперам тулкитного софта (как и девелоперам под любой из оффтопиков) не надо думать об этом: тулкиты скрывают всё, кроме независимости переключалок (она ложится на юзера в каждом дистрибутиве. До сих пор.)

Гораздо лучше, чем в вейленде.

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

Со шрифтами есть проблема.

я уже писал, что лучшие иксы в моем понимании — это исправленный хтмл

www_linux_org_ru ★★★★★ ()

Четвёртая страница:

Показано 20 сообщений из 200. Показать все.

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

Ну да, а лучший X-сервер — это исправленный хром. И вообще, за хромоосью будущее.

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

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

я уже писал, что лучшие иксы в моем понимании — это исправленный хтмл

Это никак не решит вопрос растеризации шрифтов. :}

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

Ну да, а лучший X-сервер — это исправленный хром.

нет

И вообще, за хромоосью будущее.

нет

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

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

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

Точно, нужно же отрендерить xul в этот новый html, чтобы рендерить html в html в html.

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

Это никак не решит вопрос растеризации шрифтов. :}

решает

именно:

1. аппликухе большей частью вообще не нужно знать метрики шрифтов (т.к. весь layout высчитывается на графическом сервере)

2. а если нужно, можно запросить графический сервер (т.к. шрифты там)

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

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

www_linux_org_ru ★★★★★ ()
Последнее исправление: www_linux_org_ru (всего исправлений: 2)
Ответ на: комментарий от geekless

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

Для приложения. Я с этим согласен.

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

И чем тебе тут не угодил Wayland? Тем, что он ломает существующую архитектуру? Ну так это один из способов.

в том смысле, что это наиболее эффективный способ.

Тогда встаёт вопрос о том, каковы критерии эффективности. Более того, в Wayland можно выделить отдельно API для рисования в буфер и отдельно API для скрещивания этих буферов. Правда, в сеть ты первое API скорее всего, не выгонишь.

Подход «мы тут композитим битмапы, а откуда они берутся нам пофиг» — это тупиковый путь. Это взятие за основу архитектуры какой-то второстепенной детали реализации.

Внезапно. А то, что X сервер последние пять лет (с приходом композитинга в массы) именно так и работает — это ничего?

Здесь есть одна деталь — отделение тулкитов от их бекендов позволит в будущем перекраивать графическую систему вообще как угодно, поэтому Wayland тут тормозом никаким не будет — выкинут и напишут что-нибудь ещё пострашнее.

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

Точно, нужно же отрендерить xul в этот новый html, чтобы рендерить html в html в html.

чувак, ты поверишь мне на слово, что я не полный идиот? :-)

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

в Wayland можно выделить отдельно API для рисования в буфер

в wayland по определению нет API для рисования в буфер. Всё рисование берёт на себя клиент, оно за рамками wayland. Можно определить new-graphics-system over wayland, занимающуюся рисованием, и портировать тулкиты на неё. Ну и сделать её прозрачной по сети, оставив wayland тонким слоем абстракции над железом. Но это к самому wayland никакого отношения не имеет.

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

Буферы бывают как минимум двух видов. FBO на видеокарте и битмапа в памяти. Каким пользуется вейланд?

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

в wayland по определению нет API для рисования в буфер.

А картинки в буфере волшебным образом оказываются? :-)

API есть, так или иначе. Пусть не имеет отношения.

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

Буферы бывают как минимум двух видов. FBO на видеокарте и битмапа в памяти. Каким пользуется вейланд?

Набор битмапов в памяти видеокарты. Точнее, набор текстур. Это же композитор.

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

Так. Текстура — сущность из OpenGL. Соответственно вейланду уже не пофиг как приложение будет рисоваться.

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

бугага, это для тех кто стричь будет хомячков делается.

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

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

Можно определить new-graphics-system over wayland, занимающуюся рисованием, и портировать тулкиты на неё. Ну и сделать её прозрачной по сети, оставив wayland тонким слоем абстракции над железом.

любой быдлокодер может рисовать «просто 2д (с)» — а оконную систему составляет рисование_2д + event_dispatch

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

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

Но это к самому wayland никакого отношения не имеет.

практически — имеет, т.к.

1. new-graphics-system over wayland не написана

2. даже если ее напишут, ты никого на заставишь портировать на нее гтк и кути

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

И чем тебе тут не угодил Wayland? Тем, что он ломает существующую архитектуру? Ну так это один из способов.

Мальчик, ты дурак? (c)

Более того, в Wayland можно выделить отдельно API для рисования в буфер и отдельно API для скрещивания этих буферов.

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

Внезапно. А то, что X сервер последние пять лет (с приходом композитинга в массы) именно так и работает — это ничего?

Во-первых. Если он «так и работает», нахрена нужен вейланд? Выпилите из иксового протокола все неиспользуемые вызовы и опкоды и замените подсистему обработки раскладок на более вменяемую. ВСЁ. По твоей же логике, next-gen графическая система готова. Чо они там 5 лет проектируют этот композитор несчастный?

Во-вторых, если «X сервер именно так и работает», ты не расскажешь мне, что такое NETWM, Xrender, cairo xlib backend, OpenGL и почему без всего этого добра, которое «ненужно и не используется», весь линуксовый десктоп просто невозможен?

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

Неправильно. Правильно так: «отделение кривых тулкитов от их кривых бэкэндов позволит в будущем доростить костыли даже до неба, даже до аллаха».

Вон замечательный пример с гонками www_linux_org_ru уже привел. И вот так у них всё.

Кроме того, какой, твою мать, абстрактный «бэкэнд» позволит мне реализовать панель задач или менеджер буфера обмена, или какой-нибудь i3wm так, чтобы он просто работал 10 лет без переписывания каждые полгода под новый набор костылей? (Хинт: это не та функциональность, которая покрывается тулкитом.) Без стабильного API, да. Даже без понимания необходимости проектирования такого API. Браво.

Приложение по своей сути в своих интерфейсных задачах обрабатывает ввод и рисует вывод. Это первичные сущности, это то место, по которому должно проходить стабильное и выверенное до миллиметра API. А все тулкиты — это просто внутренняя кухня приложения. Тулкиты приходят и уходят, задачи остаются те же самые.

Отсутствие такого API — это как если бы в Single Unix Specification отсутствовало API на операции с файлами. А чо, «тулкиты» справятся через прямые вызовы ядра.

geekless ★★ ()
Последнее исправление: geekless (всего исправлений: 2)
Ответ на: комментарий от www_linux_org_ru

Plot twist: new-graphics-system over wayland = Xwayland, единственное назначение wayland-композитора тут — гламурная замена *DM и xlock.

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

А картинки в буфере волшебным образом оказываются? :-)

Добрый совет:

* Открываешь документацию на wayland.

* Читаешь.

* Еще раз читаешь.

* Перестаешь писать глупости.

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

Plot twist: new-graphics-system over wayland = Xwayland, единственное назначение wayland-композитора тут — гламурная замена *DM и xlock.

насчет кухни *DM пока ниче не могу сказать

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

Нельзя. Wayland — это только и исключительно API для создания прямоугольников и отображения в них абстрактных сурфейсов.

А сурфейсы там по волшебству появляются? То, что Wayland не специфицирует это API, это не значит, что там ничего нет. Каждый тулкит велосипедит своё.

Ну, собственно, поэтому Wayland и называют маленьким, а X — большим.

Во-первых. Если он «так и работает», нахрена нужен вейланд? Выпилите из иксового протокола все неиспользуемые вызовы и опкоды и замените подсистему обработки раскладок на более вменяемую. ВСЁ.

Получится Wayland…

Во-вторых, если «X сервер именно так и работает», ты не расскажешь мне, что такое NETWM, Xrender, cairo xlib backend, OpenGL и почему без всего этого добра, которое «ненужно и не используется», весь линуксовый десктоп просто невозможен?

Всё, кроме OpenGL — это то самое API для рисования в прямоугольники, которые затем сшивает композитор. Именно так работает композитный режим в Xorg. Только там ещё куча вызовов обрабатывается, которые в композитном режиме совсем не нужны и не будут вызваны, но требуются по спецификации X.

А OpenGL никто не отменял.

Кроме того, какой, твою мать, абстрактный «бэкэнд» позволит мне реализовать панель задач или менеджер буфера обмена, или какой-нибудь i3wm так, чтобы он просто работал 10 лет без переписывания каждые полгода под новый набор костылей?

Никакой. Сейчас такого API нет, возможно оно будет.

Отсутствие такого API — это как если бы в Single Unix Specification отсутствовало API на операции с файлами. А чо, «тулкиты» справятся через прямые вызовы ядра.

Да. В Mir пошли ещё дальше — у них в Single Unix Specification отсутствует API вообще. Только тулкиты.

Тебе это кажется кошмаром и ужасом, я знаю, но оно работает.

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