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.

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

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

Колдовство называется jquery, extjs и тэпэ.

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

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

«чертов клубок» из него делают ненормальные, подверженные моде на аякс, а у нормальных людей все работает без DOM и JavaScript

Без DOM и JavaScript это язык разметки документов. Довольно хиленький, кстати.

Если натянуть на него кучу соплей на CSS и JS (CSS при этом желательно обмазать макропроцессингом, чтобы преждевременно не свихнуться), то он с грехом пополам превращается в убогий язык разметки интерфейсов. (Для хорошей разметки интерфейсов нужны совсем другие свойства языка, нежели для разметки документов. А сделать за 20 лет из html именно средство разметки GUI в W3C так и не осилили.)

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

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

«знать историю своего ремесла» недостаточно

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

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

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

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

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

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

Но чем дальше все эти детали обдумываешь, тем становится очевиднее, что не выйдет новой концепции. Потому что узких мест становится всё больше, а пути их преодоления — всё костыльнее. В итоге всё вырождаётся в еще один убогий html с js. Пусть они по-другому называются, иначе выглядят и более приспособлены для задач GUI. Но внутри они всё равно остаются убогие. Это не убожество реализации. Это по логике развития концепции оно так выходит.

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

Но что с этим статичным интерфейсом делать потом? Надо как-то с бизнес-логикой взаимодействовать.

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

для кого тогда я простыни пишу?

слова «*исправленный* хтмл» ты видел? Ситуация с Wayland: факты о X и Wayland. (комментарий)

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

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

Может и не включаю, у меня 4 утра сейчас. Пойду посплю, что ли.

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

В итоге всё вырождаётся в еще один убогий html с js.

раз вырождается, то значит в процессе мышления что-то не так

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

*кратко* набросай список узких мест

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

Может и не включаю, у меня 4 утра сейчас. Пойду посплю, что ли.

давай поспи, а потом пройдись по узким местам этой (моей) идеи и вкратце опиши их

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

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

geekless предложил удобную терминологию вида «наборы виджетов, реализованные в дисплее», предлагаю ее держаться

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

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

теперь предлагаю подумать еще раз, и найти слабые места этого подхода

(а профит, надеюсь, от улучшенного на дисплее поля ввода тебе виден)

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

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

Вполне очевидно, что всем пофиг. Как только ты предоставишь язык для расширения.

теперь предлагаю подумать еще раз, и найти слабые места этого подхода

Если ты переформулируешь решаемую проблему. Для взаимодействия разных тулкитов ты предлагаешь классическое «complex non-solution for simple non-problem».

Ах да, и еще хотелось бы услышать ответ о Rhythmbox, Gajim и Eclipse.

tailgunner ★★★★★ ()
Ответ на: комментарий от special-k

Если не секрет, чем не устраивает html, и чем не устраивает xul?

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

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

Вполне очевидно, что всем пофиг. Как только ты предоставишь язык для расширения.

не-не-не, у тебя же вроде были некие офигенно простые соображения, которые вааще рубят мою идею на корню

Если ты переформулируешь решаемую проблему.

это уже другой разговор

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

что мы имеем сейчас:

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

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

3. недостатки общего знаменателя в виде wayland тут обсудили

4. общий знаменатель в виде html+css (и его вариант с dom+js+ajax) показал себя весьма положительно, можно сказать общепризнан практически, но имеет определенные существенные недостатки (и вообще не покрывает вопросов, которые лежат вне 1 окна)

вывод, по-моему, очевиден — исправлять недостатки п.4

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

Вполне очевидно, что всем пофиг. Как только ты предоставишь язык для расширения.

не-не-не, у тебя же вроде были некие офигенно простые соображения

Что сложного в соображении «предложение не решает никаих проблем, но успешно создает новые»?

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

Мде. Вот когда ты _сформулируешь и обоснуешь_ требования к этому общему знаменателю, можно будет вернуться к разговору. А то, знаешь ли, этих общих знаменателей уже - от {get,put}pixel и примыкающего к ним Вяленда до X и RDP.

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

А то, знаешь ли, этих общих знаменателей уже - от {get,put}pixel и примыкающего к ним Вяленда до X и RDP.

а то знаю

и ты знаешь, что я знаю — см. выше п.1,2,3,4

насчет RDP — сомневаюсь, что он общий знаменатель, т.к. афайк дотнет начиная с 3.0 рисует через авалон, а авалон через директ икс

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

Что сложного в соображении «предложение не решает никаих проблем, но успешно создает новые»?

а мозги включить?

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

как, интересно, это выглядело бы, если википедия была аппликухой?

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

а еще я подставлял фотки больших размеров в мобильные сайты

и все это очень просто

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

Ах да, и еще хотелось бы услышать ответ о Rhythmbox, Gajim и Eclipse.

я в глаза не видел первое и не пользуюсь вторым и третьим (оффтопик: хотя архитектура Eclipse мне инересна, кстати, но я не знаю, где почитать именно о ней, а не вызовах апи)

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

Идея, безусловно...

... интересная. Формализовать бы её как-то. И что получится, если её добавить к «нашим баранам» как расширение? /* Давайте не будем использовать термин «костыль», т.к. это всё-таки «расширение», возможность которого предусмотрена. */

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

«предложение не решает никаих проблем, но успешно создает новые»

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

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

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

и все это очень просто

И очень ненужно. Написать стандарт, который будет удовлетворять потребностям всех современных приложений — годы работы (вероятно, ничего не выйдет: ничего с таким широким охватом пока нет). И ради чего?

note173 ★★★★★ ()
Ответ на: Идея, безусловно... от anonymous

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

я плохо представляю, каким образом этот «общий знаменатель» надо пристыковывать к иксам

т.е. для тонкого слоя абстракции над железом явно лучше всего что-то типа libsdl, но иксы, видимо, тут не мешают

для оконной системы в рамках 1 окна нужен исправленный хтмл

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

Формализовать бы её как-то.

да, хорошо бы

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

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

И очень ненужно.

если ты хомячок и согласен есть то, что тебе дают — то ешь пожалуйста, не отвлекайся

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

просто битмапы удовлетворяют «потребностям всех современных приложений», так ведь?

надо просто подняться от них, но не очень далеко

пока что наиболее сильное возражение выдвинул geekless — труднее всего будет конкурировать с html (особенно после того, как в нем появился canvas)

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

Меня больше интересовало все в разрезе html vs xul.
Но у меня теперь еще вопрос, а чем не устраивает ajax?

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

слабые места

Переносимость приложений на платформы, не использующие данный дисплейный сервер, как вариант.

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

Но у меня теперь еще вопрос, а чем не устраивает ajax?

html+css декларативные, а ajax/js скорее императивный

ajax выражает конкретную реализацию какого-то намерения, а не само намерение (а вот тэги html и css селекторы могут выражать именно намерение)

если js можно научить че-то делать с окнами, это не значит, что его нужно использовать для этого

js это такая заплатка/workaround, который, возможно, нужен в дисплее, но без которого желательно обходиться

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

html декларативный

Какая польза от этого? (я просто против гоняния фрагментов хтмл по сети)

html и css селекторы могут выражать именно намерение

Можно пример «намеренья», но сходу, не смешивание ли это логики и отображения?

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

Какая польза от этого? (я просто против гоняния фрагментов хтмл по сети)

Можно пример «намеренья», но сходу, не смешивание ли это логики и отображения?

тут надо различать 2 вопроса:

1. как писать веб-аппликухи в условиях нынешнего стека свалки технологий

2. если предположить, что html+css+... можно спроектировать с 0, то как это надо делать

по п.1: очевидно, что html+css не поддерживает mvc/mvp, поэтому проблемы там будут и выбор лучшего варианта можно делать только из плохих возможностей (хотя вроде там сделали какой-то w3c стандарт на тему data binding, не?); тут я спорить не хочу, но узнать, какой из плохих вариантов одержал временную победу, возможно, было бы интересно

по п.2:

Можно пример «намеренья», но сходу, не смешивание ли это логики и отображения?

представь, что не было бы возможности написать align=center, и для его реализации приходилось бы использовать <div align=left id=id100500> и вытаскивать его на середину ява-скриптом — вот это пример императивности вместо декларативности и реализации вместо намерения

(понятно, что еще более декларативно юзать css)

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

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

Есть. И чего мне о ней думать? В gtk вот она (GtkGrid)

ок

беглый взгляд показывает наличие gtk_widget_get_preferred_height_for_width() — т.е. «примитивным рекурсивным обходом дерева с дерганием конструкторов на каждом узле» дело, похоже, не ограничивается

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

А сделать за 20 лет из html именно средство разметки GUI в W3C так и не осилили.

ниче не имею против мытья косточек хтмл, но меня гораздо больше интересуют ПРИНЦИПИАЛЬНЫЕ проблемы *правильно спроектированного* хтмл, чем то, что W3C за 20 лет че-то-там не смогло

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

Ох и понаписали за ночь.

Поехали по порядку:

беглый взгляд показывает наличие gtk_widget_get_preferred_height_for_width() — т.е. «примитивным рекурсивным обходом дерева с дерганием конструкторов на каждом узле» дело, похоже, не ограничивается

Мне кажется, ты как-то путаешь конфиг и собственную семантику виджета. У виджета есть свойства, методы, слоты сигналов. (Как минимум, из всего этого свойства и слоты в gtk run-time inspectable). Таблица - это такой контейнер с интересной семантикой, и всё, что от него нужно, он делает.

Но мы можем эту таблицу создавать, надрачивая gtk_grid_*(blabla, blabla), а можем завернуть всё в файл конфигурации, и пусть библиотека сама с этим разбирается. Способ с конфигом — понятно — и гибче, и концептуально мощнее. Но при этом в обработке конфига никакой магии нет, это действительно тупой обход дерева.

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

Для этого достаточно, например, в gtk дать стандартный способ пользователю вмешаться в логику построения дерева виджетов и их свойств при помощи задания правил на каком-нибудь декларативном языке. Правда после этого половина существующих приложений развалится, не ожидая такого подвоха. Но это я к тому, что это в принципе возможно и при помощи application-side тулкита.

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

Проблема в том, что абстрагироваться от дополнительных примочек ты можешь («нам нужно просто поле ввода, а насколько оно удобно сделано, пусть у сервера голова болит»), а вот конкретизироваться на нах — нет. Потому что если в этом общем знаменателе нет, например, вот такого няшного поля ввода со списком, иконками и свитоперделками, то никак ты его и не получишь. Единственный способ — закачивать код виджета на дисплей, т.е. JS. И вся совместимость тулкитов на этом и заканчивается.

Теперь про недостатки и достоинства. Сначала про достоинства. Преимущества дескриптивного подхода к GUI ты уже описывал тут, посмотрим, что будет, если их развить:

1. GUI не должно быть stateless, должна быть возможность прямо из декларативного представления интерфейса работать с его состоянием. По типу «нажали на кнопочку, и представление данных в рабочей области сменилось с таблицы на сетку иконок». Какой-то язык выборки узлов интерфейса, по типу того, что используется в jquery, дополненный возможностью изменять состояние этих узлов. Пример в псевдокоде:

<a href="query: #dataarea::class(list_view)" group="view_mode" class="radioitem">Список<a/> | <a href="query: #dataarea::class(grid_view)" group="view_mode" class="radioitem">Сетка<a/>

2. Львиная доля скриптов — это тупо «отправить запрос приложению и подставить результат в какой-нибудь узел». Это тоже можно описывать декларативно, без километров императивщины на JS:

<a href="query: #dataarea::content(application::page(1))">Предыдущая страница</a> |
<a href="query: #dataarea::content(application::page(3))">Следующая страница</a>

На этом преимущества заканчиваются.

Про узкие места. Какие у нас могут быть варианты интерфейса:

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

2. Всё то же самое, но облагороженное с целью улучшения эргономики. Более интерактивные компоненты, обновление без полной перезагрузки гуя и т.п. Всё это делается сейчас на JS, но всё это можно делать при помощи декларативного языка.

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

Проблема первая: чтобы «расширить» GUI, нам нужен мощный тьюринг-полный язык на дисплее. Это сразу на корню подрезает саму концепцию «простого декларативного интерфейса».

Проблема вторая: мы ничего не знаем о том, как виджеты реализованы дисплеем, и не сможем сделать на уровне look and feel «так же, но лучше». В качестве костыля придётся переопределять на собственные ВООБЩЕ ВСЕ виджеты и натягивать на них свой собственный look.

Проблема третья: пройдёт 2 года, все разработчики подсядут на иглу этого языка, и никому не нужена будет развитая семантика декларативного языка. (Впрочем, это точно так же, как с иксами. Есть XRender и OGL, но криворукому разработчику не осилить их правильное использование, лучше повозмущаться про «иксы устарели ололо».) Даже те приложения, которым бы за глаза хватило декларативного языка, будут неюзабельны без кучи императивных костылей. Ну и производительность соответствующая.

4. Кроме того, есть еще проблема эффективного взаимодействия с дисплеем для вывода «быстрой» графики. Растровые и векторные изображения, видеопоток, OGL и т.п. Но это в принципе решаемо.

И еще: всё это требует очень аккуратного программирования со стороны авторов фреймворков и прикладных программ. Потому что интерфейс дисплея будет предлагать как высокоуровневые возможности, в семантике готовых виджетов, так и возможности для сырой обработки ввода и вывода. Будет очень много вариантов, как можно это API использовать НЕПРАВИЛЬНО. (Частный случай я выше называл.) Соответственно, это налагает довольно высокие требования на чувство архитектуры у прикладного программиста.

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

просто битмапы удовлетворяют «потребностям всех современных приложений», так ведь?

Более обще — аппаратно-ускоренные поверхности. Да, они удовлетворяют, потому что позволяют сделать все. В языке разметки все предусмотреть невозможно.

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

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

. Ах да, и еще хотелось бы услышать ответ о Rhythmbox, Gajim и Eclipse.
я в глаза не видел первое и не пользуюсь вторым и третьим

Больше вопросов нет.

tailgunner ★★★★★ ()

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

cast ckotinko

У меня такие вопросы:

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

2. Я правильно понимаю, что выделив несколько таких буферов, можно затем запускать произвольные пиксельные шейдеры для композитинга фрагментов между ними? Т.е, например, если мне нужно сделать произвольную операцию над пикселями, например, такую: dest.a = (src.r + src.g + src.b) / 3.0 , я могу скомпилировать шейдер, загрузить на видеокарту и запустить его для обработки указанных буферов?

3. Если у меня есть буферы в разном формате, насколько это усложняет работу? Например, один буфер хранит 8-битные целые, а второй 32-битные флоаты? Современное железо позволяет гибко работать с зоопарком форматов?

4. Как соотносится высокоуровневый OGL с более низкоуровневыми API графического стека? Если я на более низком уровне API выделю буфер, то потом без проблем смогу для рендеринга в него инициализирвоать машину состояний OGL?

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

6. И какие вообще почитать мануалы по современному графическому стеку драйверов?

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

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

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

ХТМЛ-like и виджеты в качестве протокола display сервера - это действительно как-то упорото. Нужно все же двигаться ниже, на уровень примитивов для отрисовки (квадратики, линии), но не так низко когда остаются только одни битмэпы.

Наверное можно глядя на текущий набор потребностей в приложениях найти такой набор 2д команд который бы сильно уменьшил трафик между клиентом и сервером (т.е. был бы эффективнее битмэпов).

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

1. да. у радеонов есть на борту MMU с двухслойной организацией(как на х86-32). вроде бы у интела вообще MMU содран с процессорного 1-в-1. нвидия НЯП тоже не сильно выделяется из общего стада.

2. да. но на практике пиксельные шейдеры требуют как минимум 1 render-target а opencl ничего вообще не требует

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

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

4. херово они относятся. в теории можно использовать libdrm напрямую, но никто из высокоуровневого api не будет жрать твои хендлы. этот момент просто никем не продуман. на практике можно выделить через DRI2 буфер и рисовать по-waylandовски -это в иксах. более того, только с DRI2 будет работать акселерация видео в интелодровах. но вот fglrx просто в упор не поймёт что это за буфер такой. как раз изза того щас геморой имею.

5. да.

6. мануалы по интеловидяхам на сайте интела - очень хорошие. амдшные на x.org/docs

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

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

В моей голове разве что.. Очевидно не хватает хука к конструктору элементов, тогда можно было бы, в соответствии с параметрами, биндить данные. С другой стороны, хтмл критикуют за громоздкость, сложность написания, и популярность всяких jade и haml подтверждает это. По сему, решение - это DSL, в котором не будет разницы между стандартными и «измененными» тэгами (т.е. виджетами). Хотя некоторые применяют для подобных вещей json, лично я склоняюсь к js, т.к. каждый виджет придется писать, и делать это придется на js, а dsl на js тогда будет применим как снаружи, так и внутри виджетов. Сам js в нынешней форме не подходит, он опять же довольно громоздкий, это неизбежно, это jit компилируемый язык, он должен компилироваться быстро, потому ждать там синтаксического сахара не приходится.. Выход - трансляторы, но не такие, сильно отличающиеся от js, как coffee (хотя я использую его сейчас), а более похожие на js (не так уж много надо изменить в js, чтобы он стал менее громоздким).

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

общий знаменатель в виде html+css (и его вариант с dom+js+ajax) показал себя весьма положительно

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

Если бы у разработчиков была возможность просто рендерить картинки на сервере, отдавать клиенту, а потом получать от клиента координаты кликов и сканкоды клавиш (а html это уже позволяет) — мигом бы начали рисовать всё нестандартное именно таким способом, потому что делать всё в JavaScript — лениво.

Ну и, таким образом, мы получим те же грабли.

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

Ох и понаписали за ночь.

ага, и еще понапишем, только постепенно

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

ХТМЛ-like и виджеты в качестве протокола display сервера - это действительно как-то упорото. Нужно все же двигаться ниже, на уровень примитивов для отрисовки (квадратики, линии), но не так низко когда остаются только одни битмэпы.

ок, попробую двинуться ниже

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

как-то убого это — жалкое подобие хтмл

з.ы. css должен задавать не только правила отрисовки отдельного прямоугольника, но группы прямоугольников, собранных в grid/layout/..., а иначе получим моргание и дергание

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

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

Дальше можно не читать.

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

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

попытка двинуться ниже приводит к чему-то вроде scene graph with display-side css

www_linux_org_ru ★★★★★ ()
Последнее исправление: www_linux_org_ru (всего исправлений: 1)
Ответ на: Коллега,... от anonymous

Со своей стороны могу так же заметить что если Х12 получат развитие, то мои ребятишки смогут поддержать проект в части сети. И в части безопасности в первую очередь. Но на условиях анонимности.

Oh you!

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

Больше вопросов нет.

я очень рад, что тебе все ясно

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

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

Мое предложение: если кто-то готов исследовать подсистемы Xorg - я готов проинвестировать его деятельность.

хорошая кстати мысль — в том смысле, что нашей системе (не только иксам) очень не хватает *архитектурных* решений, и софт *в целом* развивается в стиле «лебедь, рак и щука»

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

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

А почему не целые картинки, которые так легко гонять через Shared memory?

Мы ведь обсуждаем сетевую прозрачность? Очевидно, что целые 4K картинки гонять по сети более накладно, чем битстрим оригинального упакованного видео.

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

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

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

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

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

Зачем по вашему отделять «css» от «html» в такой системе? Вообще говоря текущие API создают такого рода «css», например в офтопике вызываем CreateBrush() и получившийся хэндл используем для отрисовки разного рода объектов. Вроде в иксах аналогично, парамтеры графических операций определяется в GC. Это позволяет немного уменьшить трафик в тех случаях когда когда один и тот же «стиль» применяется к нескольким объектам. Однако работает это не как в браузерах, когда в начале вы получаете CSS и потом используете его на разных HTML.

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

з.ы. css должен задавать не только правила отрисовки отдельного прямоугольника, но группы прямоугольников, собранных в grid/layout/..., а иначе получим моргание и дергание

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

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

Пожалуй, это не имеет смысла...

... на 1000-м постинге до меня начинает доходить что копаем глубоко, но похоже не в ту сторону... =) Нам бы по-хорошему дотянуть Х11 до Х12, а мы тут уже супер-спецификации супер-протоколов готовы родить... =) IMHO, несколько не то... =)

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