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.

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

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

А ты попробуй — тебе с твоими запросами ничего больше наверняка и не потребуется. Другое дело за это деньги предётся платить — ну это жизнь такая и за бесплатно облизывать тебя никто не будет.

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

Просто они уйдут или запилят свой удобный дистрибутив

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

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

А ты попробуй

Пробовал. Неудобное говно с хреновой графикой.

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

Хотя, конечно, по пьяне или накуре зарубиться с кем-нибудь в файтинг - тут приставочка очень хороша, да. Но не более.

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

Ну, когда видно, что индивид наваливает кучу дерьма, то выражать ему любовь и обожание как-то странно.

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

индивид наваливает кучу дерьма

Это некоторой илитке с опухшим ЧСВ так кажется, всего лишь :)

fragmentor ()

Мысленный эксперимент: Rekonq поддерживает Xinput 2.2, библиотеки KDE — Xinput 2.0, а плагин Flash — только базовый X11. Все они будут определять, какая версия подсистемы ввода поддерживается браузером Rekonq, и в результате будет отдана одна версия для работы со всем вводом... И это может быть не та версия, которая имеет всё необходимое.

бгг, а в вяленом Flash работать не будет, потому что там никакого XInput. Проблема решена, аплодисменты!

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

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

Хм. Ну в общем-то, это и требуется.

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

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

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

Я просто умнее тебя

Умнее ты или нет - вопрос десятый, суть в том, что у тебя ЧСВ лезет изо всех щелей, поэтому ты свои глюки принимаешь за самую настоящую реальность :D

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

Примитивами в данном случае являются слайсы из битстрима медиа файлов

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

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

CM и WM - это отдельные задачи. С какого перепугу они должны быть прибиты гвоздями друг к другу?

Так получилось.

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

Итак, выходим в инет с нетбука через wi-fi роутер, динамический ip, к примеру, файрволл, все дела, подключаемся через ssh -X к удаленному хосту с предварительно запущенной ранее xpra сессией смотрим результат и хотим его распечатать (или сохранить) ... и тут понимаем, что пилят, надо было пробросить порты на роутере и разрешить доступ ... Настраиваем cups(нужен рут на удаленной машине), sshfs (рут не нужен, только пароль). Ни разу не геморройно, ага. Главное, сетевая прозрачность же :-)

Так это... был в иксах принт-сервер, так выкинули ведь «инноваторы» хреновы.

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

Pixmap тоже примитив.

Который и гоняется через shared memory. Так это аргумент за или против?

Aceler ★★★★★ ()
Ответ на: Сетевая прозрачность не нужна. от r5ha

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

Всякий раз, когда очередной неофит врывается в экосистему Линух и начинает усиленно проталкивать свой велосипед, крича на каждом углу, что его велосипед значительно быстрее, я недоумеваю, а до него что-ли все было медленно. Меня скорость X и 15 лет назад устраивала, когда в компе было 32 Мбайт и какой-нибудь Pentium 100 МГц.

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

Не смешите мои тапочки. Разберитесь хоть немного в вопросе для начала. Одним из важнейших преимуществ X от рождения над GUI Windows, Mac и пр. в свое время было то, что X были именно сервером с механизмом обмена сообщениями с клиентами. В Windows 9х с окошком зависшего приложения хрен что сделаешь. А в X этих проблем не было. Главное, что приложение и оконная подсистема это самостоятельные процессы, а способ IPC это уже дело десятое. Коль скоро X-ы были именно сервером, то сетевую прозрачность в них грех было ни реализовать. Кстати, вспомнилось вдруг. Когда BeOS только вышла, в каком-то журнале прочитал сравнение её возможностей с Win 9x. Одним из достоинств BeOS там упоминалось, что в ней даже перемещаемое мышью окно обновляется в процессе перемещения. Вах - подумал я. Запустил какой-то видеоролик под Linux, подвигал окно при этом и подумал - а зачем BeOS, когда есть Linux с X, где все это уже реализовано.

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

Если бы они думали о пользователях, то создавали бы прикладной софт, которого до сих пор не хватает, а не переделывали то, что и так хорошо работает. По части GUI какая-нибудь Федора 4 меня устраивала на 99%. Глюки бы в ней подчистили, и было бы на 100%. А нынешних десктопных средах я уже начинаю встречать всякого рода фризы и прочую хрень. Такое впечатление, что ко мне возвращается Win 9x.

Их потребности могут быть удовлетворены на все сто некоторым плагином, который бы устанавливался на оба компьютера (клиента и сервера), устанавливал TCP-соединение и эмулировал команды клиента на удалённом рабочем столе, по аналогии с RDP в Windows. И для этого не нужно городить сеть в самой графической системе.

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

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

в общем-то, это и требуется.

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

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

Сетевая прозрачность в иксах сейчас ничуть не лучше чем в вяленом. А то и хуже учитываю что в вяленом уже есть реализация RDP и VNC

Ага, ага. То, что там есть - назвать «RDP» ну никак нельзя. Это скорее VNC over RDP, т.к. есть тупо гоняние картинок, что не сильно эффективнее VNC но зато хуже исков.

Magister2k7 ()

должен справиться с этой задачей лучше чем X

должна появиться почти совершенная обратная совместимость

Каждый кадр будет идеальным

Мы способствуем славному будущему Wayland

Стоп, что он сейчас умеет? Нет ну правда? Ну сколько лет его разрабатывают? И что? Другое дело, что обратная совместимость, особенно «идеальная» меня радует, я начинаю менее скептично относится к Wayland.

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

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

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

Если приличное ПО пишут преимущественно под Gtk, на это должна быть серьёзная причина. Ведь писать приложения на плюсах и Qt легче, чем на C и Gtk.

10 лет назад создавались эти приложения — вот и вся причина.

quiet_readonly ★★★★ ()

Интересная статья. Так чего же ждать раньше - мир или вейленд?

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

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

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

Собственно и Qt5 и GTK3 такой слой есть, в EFL скорее всего тоже. Так что разработчикам Mir не так уж много делать придётся, и в Qt уже всё готово.

quiet_readonly ★★★★ ()

Кстати, пользуясь случаем, хотелось бы многое для себя прояснить. Из того, что я прочел в этом треде и ранее, я понял, что Вяленд исключительно реализует функционал выдачи приложению некой области экрана (окна) и управления параметрами вывода в эту область (прозрачность и прочая). Все остальное должны делать приложения и еще фиг знает что. Тогда вопросы: 1. Как приложение будет рисовать в окне? У каждого графического тулкита должен быть реализован интерфейс с чем (драйвером видюхи)? 2. Как и чем будет реализован ввод, управление фокусом и т.п.? Каждый тулкит будет со своим велосипедом ковыряться в своем окне? 3. Как будут реализованы DnD и clipboard?

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

Я считаю что раст должен рисоваться растром (видео, картинки), а вектор — вектором (кнопки, менюшки и прочие виджеты).

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

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

А с этим уже сложнее.

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

Так что разработчикам Mir не так уж много делать придётся, и в Qt уже всё готово.

Разработчики Mir вообще обещали сделать бекенд для X и Wayland, так что тут вообще никаких проблем не намечается.

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

Разработчики Mir вообще обещали сделать бекенд для X и Wayland, так что тут вообще никаких проблем не намечается.

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

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

1. Как приложение будет рисовать в окне? У каждого графического тулкита должен быть реализован интерфейс с чем (драйвером видюхи)?

Как сейчас. Контекст OpenGL будут получать через EGL вместо GLX.

Как и чем будет реализован ввод,

В протоколе вейланда

управление фокусом и т.п.?

Не знаю

Как будут реализованы DnD и clipboard?

В протоколе вейланда.

Для мира всё то же самое, только фокусом тоже будет рулить Mir. Он предоставляет отдельный API для приложений и отдельный API для оболочки.

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

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

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

tailgunner ★★★★★ ()

Сетевая прозрачность... Даже не знаю что это. Но если оно может позволить мне держать одну машину с windows для удалённой игры или работы в «мсофис» в домашней сети, хотя бы. Я наверное не отказался бы. А если бы ещё ресурсы разных машин с разными ос можно было объеденять для вывода графики... Мне не понятно почему нельзя чётко фрагментировать задачи и использовать модульную структуру? Зачем что то выбрасывать? При всём при этом я имея core i7 против PIII когда-то должен смотреть на прыгающий значок, вращающиеся кружок, песочные часы, текстикули перед тем как послушать музыку. Почему браузеры работают хуже чем на селероне н-лет назад?

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

Как сейчас. Контекст OpenGL будут получать через EGL вместо GLX.

В чем тогда профит, если как сейчас? Кстати, а QT и GTK сейчас рисуют только через OpenGL?

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

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

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

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

Да.

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

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

Оба на. Тогда получается та же двойная буферизация, ну разве только буфер отдается через shared memory, а не через канала/сокет. Что-то как-то чем дальше, тем меньше оказывается преимуществ у Вяленда.

Кстати, а почему в принципе нельзя рендерить OpenGL & etc на стороне X-сервера? Я так понимаю, что исключительно по причине сложности программной реализации?

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

Что ты всё 9x да 9x, попробуй современный Windows на ядре NT, думаю у для тебя будет такой же шок как и при переходе с 9x на Linux 15 лет назад :)

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

В чем тогда профит, если как сейчас?

Профит в том, что 90% возможностей иксов не используются. Разработчики тулкитов реализовывают функции, которые никогда не будут вызваны. Xorg покрыт расширениями, которые никогда не будут использоваться. Разработчики приложений предусматривают ситуации, которые никогда не случатся. Разработчики драйверов пишут и поддерживают инструкции, которые никогда не будут вызваны.

Иксам известна настоящая драма.

Aceler ★★★★★ ()

Линукс до боли напоминает СССР. Не имеем своих планов, не дорожим своим, не развиваем, смотрим на «запад». Они забацали, мы ответили.

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

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

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

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

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

Это почему-же?

Да что там говорить, даже шрифты уже лет десять как рендерятся в битмапы на клиенте и гоняются на сервер !

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

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

Это почему-же?

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

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

Что ты всё 9x да 9x, попробуй современный Windows на ядре NT, думаю у для тебя будет такой же шок как и при переходе с 9x на Linux 15 лет назад :)

Насколько я понимаю, то, что окнами должен управлять отдельный процесс, до разработчиков Винды дошло только к Висте. У делателей Вяленда похоже пошел обратный процесс - решили постепенно к Win 9x пойти.

zloy_starper ★★ ()

на первый взгляд, старые иксы уродливы

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

Что-то как-то чем дальше, тем меньше оказывается преимуществ у Вяленда.

Как гром среди ясного неба! Такое ощущение, что вейланд не сразу задумывался таким костыльным, и об этом не твердили более девяти тысяч раз с первой теме о вейланде на лоре.

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

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

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

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

Ну не совсем. Как сказать X-серверу нарисовать толстую линию со сглаживанием, если этого нет в протоколе?

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

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

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

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

Пилильщиков хейтеров сустемд, пульса, кед и гнома просто навалом. Осталось выбрать, куда идти.

anonymous ()

Шрифты отданы клиентам.

Это фэйл. Простейшее приложение получится жырным, не будет единообразия.

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

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

«В X есть сетевая прозрачность» — её нет. Базовый протокол X и DRI-1 имели сетевую прозрачность, но никто не использует ни то, ни другое.

Ну, это вы, ребята, мягко говоря погорячились насчёт «никто».

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

Это фэйл. Простейшее приложение получится жырным, не будет единообразия.

Сейчас по факту уже так.

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