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.

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

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

Тебе можно дернуть ещё zubok, vitus из здешних. vkni на опеннете. они что-то формулировали вполне вменяемое.

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

Тебе можно дернуть ещё zubok, vitus из здешних. vkni на опеннете. они что-то формулировали вполне вменяемое.

Ну и тебя, коллега анонимус :)

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

Видимо, здесь мне тоже «нужно вмешаться».

«Позиция человека» заключается в том, что переписывать с нуля код проекта (а там, кроме libfm, всё завязано на gtk и требует переписывания с нуля) нецесообразно. Это потерять 2-3 года на исправление всех детских багов и восстановление той функциональности, что наработана сейчас.

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

Некоторыми это воспринимается как «наговорить гадостей». O_O

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

Нормально. Переписывание - это занятие ерундой.

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

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

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

Нормально. Переписывание - это занятие ерундой.

По большому счету этим в основном только и занимаются. Gtk 1.x, 2.x, 3,x. С qt я вообще со счета сбился. Причем, сказать, что что-то прям кардинально изменилось за 10 лет в лучшую сторону на десктопе, я не могу. Скорее даже некий регресс наблюдается.

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

Ну и хрен с ней, я не говорил, что она многопользовательская, просто в ней достаточно грамотно реализован механизм RDP

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

архитектурно реализация этого «грамотно» ВНЕЗАПНО весьма напоминает иксы. Команды GDI редиректятся клиенту, и там уже рисуется что надо. Ничего не напоминает? (А если залезть глубже в графическую систему шиндошвс - то можно увидеть, что там примерно тот же пайплайн и шаредмем, как и в иксах, только завернуто в другую обертку. Иксы можно сделать местами синхронными, у меня даже прототип модуля xorg где-то был для синхронного ресайза +модуль для поддержки этого в gtk). Только стоит вспомнить, что RDP - это протокол «удаленного рабочего стола» - сессия привязана к залогиненному пользователю, соответственно у тебя не получится одно приложение запустить локально, а другое, от этого же пользователя - на соседнем компе. И даже теоретически у тебя не получится использовать в rdp сканер, например, без костылей сторонних производетелей всего за $99. И с принтерами не всё гладко - оно иногда работает, а иногда у тебя глаза на лоб лезут, что шиндошвс терминал сервер делает с принтерами - «попробуйте завершить сеанс и войти снова». Мой многолетний опыт кричит о том, что реализация RDP в шиндошвс - говно. Не в последнюю очередь из-за архитектурных особенностей системы и её проприетарной сущности.

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

Ну и его можно...

... я послежу за темой. Будет куда — присоединюсь. =)

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

Не увидел, что запускается два инстанса WM/GDI, увидел один инстанс WM/GDI и GDDs.

это архитектура. Грубо говоря CSRSS (x11proxy, oops) для каждого сеанса winlogon грузит соответствующие драйвера (в случае терминального подключения это «Remote Display Driver» и перенаправляет пайплайн gdi и мышку-клаву в сервис, обрабтывающий rdp-tcp подключение , а уже этот сервис, в свою очередь - посылает всё это клиенту (x11) . Или ты думаешь, что RDP-клиент работает в сферическом вакууме и не использует графическую систему? )

Ты потерял нить, я говорил о гибридной графике

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

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

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

Небось ещё и по КОИ-8 плачешься?

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

Решил проверить и это)
У меня есть пара машин на squeeze.
Запустил на одной удалённо гном сессию через xinit /usr/bin/ssh -X gnome-session — :1, потом из этой сессии подключился к другой машине на squeeze, и запустил links2 -g, всё в локалке правда, но тормозов опять нет.

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

добавили только в спермерочке

А «семь» как будет по-вашему?

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

По идее, должно...

... но я не настолько продвинут в Дао лоркода. =)

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

Тормоза иксов проявляются на длинных пингах, а не на узких каналах. Приложения с сервера на соседней улице работают куда лучше, чем с хостинга в США. Хотя ширина канала одна и та же.

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

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

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

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

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

Это очень слабая отмазка, особенно в контексте обсуждения.

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

Это не «отмазка», а указание на ошибку собеседника. Особенно в свете существования xcb.

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

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

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

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

а указание на ошибку собеседника. Особенно в свете существования xcb.

ОК, расскажи мне, как мне заюзать XCB так, чтобы links2 перестал тормозить.

А то мне всё время рассказывают про то, какие хорошие вещи есть в иксах, мне всё время интересно «а что ж не пользуетесь»?

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

Разговор получается примерно следующим:

— В текущей реализации иксового протокола есть проблемы производительности.

— Wayland (Mir, VNC, whatever) вообще не предназначен для производительной работы по сети, проблема решена!

Отличная логика, бро.

Ты не замечаешь, как подменяешь предмет разговора, нет?

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

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

Ты не замечаешь, как подменяешь предмет разговора, нет?

Ну какбе это ты влез в середину контекста, не я. А теперь для тебя открытие, что у треда был контекст? :)

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

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

Нет каких-то «непредсказуемых случаев», есть синхронная xlib и асинхронная xcb. Это всё.

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

Конкретная реализация вейланда может точно так же показывать тормоза или реактивность по сравнению с другой реализацией, — и ты точно так же возьмешься говорить про «непредсказуемую производительность»?

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

Нет каких-то «непредсказуемых случаев», есть синхронная xlib и асинхронная xcb. Это всё.

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

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

Конкретная реализация графического сервера, или конкретная реализация протокола передачи изображения, но не конкретная реализация приложения.

Чувствуешь разницу?

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

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

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

Чем портирование тулкита на xcb принципиально отличается от портирования на libwayland?

Конкретная реализация графического сервера, или конкретная реализация протокола передачи изображения, но не конкретная реализация приложения. Чувствуешь разницу?

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

Это во-первых. Во-вторых возможности протоколов несопоставимы. Когда тебе по сети придётся прокидывать не просто прямоугольник пикселей, а весь тот набор метаданных, который необходим для нормальной интеграции окна в рабочее окружение, все проблемы длинного пинга вылезут на тех же самых местах. Вейланд ничего магического в себе не содержит, на низком уровне это точно такой же механизм удаленного вызова процедур, как и X11: request - reply - request - reply...

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

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

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

Это понятно. Возможно внедрение XCB это решит.
Но причем тут шрифты на стороне клиента? Их не долго отрендерить, тормозить не должно.
Может тормозит не из-за шрифтов?

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

Чем портирование тулкита на xcb принципиально отличается от портирования на libwayland?

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

при которой клиентскую сторону

Секунду, если у Wayland нет сетевой прозрачности, откуда там клиентская сторона? :-)

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

Приложение будет тормозить — ОК. Нет, серьёзно, ОК, приложение может тормозить. Но оно будет тормозить и локально, и удалённо, поскольку если гонять битмапы по сети — пофиг, как эти битмапы были нарисованы.

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

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

Может тормозит не из-за шрифтов?

На видео хорошо видно, на выводе чего происходят тормоза.

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

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

Претензии к тому, что реализации протокола две, что-ли?

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

Претензии к тому, что реализации протокола две, что-ли?

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

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

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

Ы? Так может все сделать еще проще? Заменить в протоколе иксов все магические числа на другие, переименовать и сами хидеры, запилить xcb с новыми хидерами, а xlib выкинуть из репозитория? Эффект будет тот же.

Секунду, если у Wayland нет сетевой прозрачности, откуда там клиентская сторона? :-)

Еще одна попытка под...ь вместо конструктива? Aceler, вот ты, сюдя по блогу, вменяемый чувак. Или это видимость?

Но оно будет тормозить и локально, и удалённо, поскольку если гонять битмапы по сети — пофиг, как эти битмапы были нарисованы.

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

пофиг, как эти битмапы были нарисованы

Если тебе нужно, чтобы удаленные приложение не тормозили, то совсем не пофиг. Впрочем, уже понятно, что тебе это не нужно.

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

На видео хорошо видно, на выводе чего происходят тормоза.

А ты сам не видишь по своему видео, что приложение выводит по одному символу по очереди? (И на каждом символе получает round-trip, а возможно и не один.) Поскольку это порт изначально консольной программы, то это абсолютно не удивительно: как логика приложения подсказывала, так костыль и прикрутили.

Я тебе скажу, что будет на каком-нибудь теоретическом вейланде и прочих VNC. Это приложение будет точно так же посылать отдельные пакеты обновлений на каждое знакоместо и висеть на round-trip-ах 90% времени. Потому что оно так криво написано.

Вопрос: при чем тут иксы?

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

Насчет LXDE печально. Правда чтоли хотят переписать на QT. Есть ссылочка на обсуждение?

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

Насчет LXDE печально. Правда чтоли хотят переписать на QT. Есть ссылочка на обсуждение?

Погугли в архивах списка рассылки за апрель-май.

Вот из личной переписки с одним из девелоперов:

    А, кстати, таки да. GTK2 со временем перестанет работать (учитывая
медленное, но верное надвижение Wayland), GTK3 это мертворождённое дитя
гнома (ага, ввели в 3.0 новое API, объявив предыдущие устаревшими, затем
в 3.4 следующая замена и теперь 3.0 объявили устаревшим, что нам теперь,
каждые несколько подверсий переписывать код?) так что мы его поддерживать
отказались, остаётся только Qt, будем постепенно на него переползать.

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

Так может все сделать еще проще? Заменить в протоколе иксов все магические числа на другие, переименовать и сами хидеры, запилить xcb с новыми хидерами, а xlib выкинуть из репозитория? Эффект будет тот же.

Придётся это обозвать X12 :-)

Про то, что Wayland заодно выкидывает не только xlib, но и, например, требование поддержки событий перерисовки областей, т.е. сильно упрощает написание тулкитов, тебе насрать? )

Еще одна попытка под...ь вместо конструктива?

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

Пусть всё тормозит.

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

Если тебе нужно, чтобы удаленные приложение не тормозили, то совсем не пофиг. Впрочем, уже понятно, что тебе это не нужно.

Да, нужно, чтобы локальные приложения не тормозили. Это главное.

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

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

В общем, как и предсказывалось умными людьми, разработка гномерами убогого gtk3 приводит к постепенной потере этим тулкитом позиций. И gtk3 стоило бы честно назвать libgnome3, потому что это де факто «библиотека для окошек гнома», а не независимый тулкит. 03.05.2013 LXDE хочет мигрировать на Qt

Но по качеству продукт получился полностью отстойным, и никакой положительной мотивации использовать его у сторонних разрабов не возникает. LXDE хочет мигрировать на Qt (комментарий)

Что изменилось-то за месяц?

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

Я тебе скажу, что будет на каком-нибудь теоретическом вейланде и прочих VNC. Это приложение будет точно так же посылать отдельные пакеты обновлений на каждое знакоместо и висеть на round-trip-ах 90% времени.

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

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

Что изменилось-то за месяц?

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

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

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

Оно будет рендерить в локальный буфер по одному знакоместу и после каждого знакоместа вызывать синхронизацию сюрфейса. Вопрос: тут приложение надо фиксить или сервер?

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

В моей позиции ничего:

Я по поводу фразы: «Все страшные сказки про gtk3 при внимательном рассмотрении оказываются именно сказками.»

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

Вопрос: тут приложение надо фиксить или сервер?

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

Читай топик: «Каждый кадр будет представлен в правильном порядке (возможен сброс лишних кадров<…>»

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

Про то, что Wayland заодно выкидывает не только xlib, но и, например, требование поддержки событий перерисовки областей, т.е. сильно упрощает написание тулкитов, тебе насрать? )

Кто это сказал, что отсутствие одного события «сильно упрощает» тулкит? Можно это упрощение как-то зримо оценить в виде количества строчек, начинающихся на знак минус в выводе diff?

И винду эти же самые тулкиты уже не поддерживают? В винде необходимость принудительной перерисовки окна никуда не делась.

Во-вторых, у любого тулкита УЖЕ есть механизм выборочного обновления поверхности. Реакция на expose - это, извини меня, 3 условных строчки кода. Прочитать переданные в expose прямоугольники, сформировать запрос на инвалидацию и поставить его в очередь. Всё.

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

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

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

Отрисовка на локальном видеоускорителе в плане требований к ПО ничем не отличается от отрисовки на удаленном видеоускорителе. Общий принцип: только писать и никогда ничего по возможности не читать обратно. Грамотно спроектированное и оптимизированное приложение для OGL будет показывать и при работе по сети приемлимый уровень производительности.

Разделение клиент-сервер должно проходить именно по линии рисующего API. Потому что даже на локальной машине оно УЖЕ там проходит.

Это настолько всё очевидно любому, кто хотя бы минимально серьёзно занимался графикой, что вопрос стоит даже не в области, куда отправлять команды OGL, на локальный или удаленный ускоритель, а в области «какое нам замутить новое рисующее API, которое с одной строны не будет таким навороченным как OGL, а с другой стороны будет более удобно для рисования графических интерфейсов, чем OGL опять же».

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

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

Я по поводу фразы: «Все страшные сказки про gtk3 при внимательном рассмотрении оказываются именно сказками.»

Ну пока в gtk3 ничего не поломали.

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

Так речь про API? А к качеству-то тулкита претензии остались?

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

А к качеству-то тулкита претензии остались?

Если сравнивать gtk2 и gtk3, то претензия по качеству у меня одна: это жалкое подобие css замедляет отрисовку приложений, и при этом даже особого упрощения в разработке тем оформления не даёт. Т.е. зачем делалось - не понятно.

Если в целом, то есть определенные проблемы с производительностью, равно как и архитектурные. Вот сейчас вроде там народ взялся за оптимизацию icon view, хорошо бы, если продолжали в том же духе, а не изобретали всякие свистопределки вроде виджета «переключатель».

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

LXDE не хватало в первую очередь стабильности. Была надежда, что мало помалу глюки будут исправляться и падения станут реже.

Но если сейчас пойдет переход на QT, то прощай стабильность.

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