LINUX.ORG.RU

Wayland — разъяснения от разработчиков KWin

 , ,


0

3

Дисклаймер. В связи с тем, что очень многие (почти все) здесь не понимают, зачем нужен Wayland, пишу в новости, благо есть источник, где кое-что разжёвано. Текст чуть-чуть подсократил, чтобы не захламлять.

Итак, приступим.

  1. В Wayland может быть реализована сетевая прозрачность.

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

  2. Сетевая прозрачность X11 не подходит для современных приложений.

    Она давно устарела, будучи сделанной с расчётом на то, что приложения используют простые команды для отображения содержимого окна, и эти команды можно отправлять по сети. Когда-то это было разумно, но современные приложения не используют X11 для рендеринга, они используют такие технологии как Cairo, Clutter, QPainter (Raster) или OpenGL. В этом случае X11 вынужден отправлять по сети готовую картинку, а для этой ситуации есть технологии, которые делают это гораздо лучше, чем X11. Сетевая прозрачность в X11 померла и так, без участия Wayland.

  3. X11-приложения будут поддерживаться.

    Никто не хочет ломать систему, переход на Wayland будет произведён если и только тогда, когда X11-only приложения будут в ней хорошо работать (через слой совместимости). Сетевую прозрачность X11, очевидно, тоже можно будет использовать.

  4. Сетевой прозрачности не место в оконной системе. Если вы хотите быстрой сетевой прозрачности, ей место в тулките виджетов.

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

  5. «Дистибутивы выкинут иксы, моё любимое X11-only приложение не заведётся!»

    Для этого уже есть слои совместимости (X11 приложения можно запускать из композитора Wayland). Поддержку X11 никто не выкинет из дистрибутивов, пока она будет востребована, даже Mac OS X всё ещё поддерживает X11 для совместимости. Постепенно количество X11-only приложений будет уменьшаться (переписывание, естественная смерть), и даже если из вашего дистрибутива поддержку X11 уберут, вы всегда сможете её собрать сами.

Прекратите повторять ошибочные утверждения.

P.S. Отвечу на вопрос «Зачем вообще нужен Wayland, давайте улучшать X11».

Такие (или аналогичные) изменения даже если были бы возможны в X, всё равно бы сломали X11 и дали несовместимый с ним X12. Без слоя совместимости обойтись невозможно, а сам X12 тоже был бы не сахар, так как писался бы с оглядкой на X11. И чем это было бы лучше того, что мы имеем с Wayland?

В основе X11 лежат архитектурные решения более чем двадцатилетней давности (см выше). Так делать уже не надо, очень много функциональности иксов перешло в тулкиты, ядро, D-Bus, и другие системы. Замену легче написать с нуля, которая делает только свою прямую работу, а не пытается объять всё.

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

★★★★★

Проверено: svu ()
Последнее исправление: cetjs2 (всего исправлений: 11)
Ответ на: комментарий от PolarFox

Этот library мог изначально не вписываться в архитектуру kwin.

Из этого получается что велосипедизм в реализации наносерверной части это уже проблемы kde/kwin/compiz, а не wayland.

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

вот и на кой тогда этот x11 нужен

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

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

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

> Из этого получается что велосипедизм в реализации наносерверной части это уже проблемы kde/kwin/compiz, а не wayland.

Нет, из этого получается, что вейленд писали лютые велосипидоры.

Если на смену html красноглазики внезапно сделают какую-то хрень, то невписываемость этой хрени в файрфокс будет проблемой файрфокса?

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

Линукс на декстопе без зубной боли официально с 2000 года, то есть с года появления опенофиса.

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

вендовый rdp отлично работает на 1mbit независимо от того на каких тулкитах пускаешь в нем приложения.

Не будет откровением, что MS в RDP нагло взяла идею X11 с графическими примитивами. Смотрим документацию на Remote Desktop Protocol: Graphics Device Interface (GDI) Acceleration Extensions и читаем:

1.3   Overview
  The Remote Desktop Protocol: GDI Acceleration Extension reduces the bandwidth associated with
  graphics remoting. The following sections provide an overview of the major components of this
  protocol and how bandwidth reduction is achieved.

1.3.1     Accelerated Graphics
  The remoting of graphics images (see [MS-RDPBCGR] sections 2.2.9.1.1.3.1.2 and 2.2.9.1.2.1.2) is
  accomplished by continuously sending updated bitmap images from server to client. Even though
  these bitmaps may be compressed, it is still not a bandwidth-efficient mechanism to employ,
  especially when dealing with graphics-intensive applications that refresh regularly.
  The Remote Desktop Protocol: GDI Acceleration Extension aims to reduce the bandwidth associated
  with graphics remoting by encoding the drawing operations that produce an image instead of
  encoding the actual image.
  For example, instead of sending the bitmap image of a filled rectangle from server to client, an
  order to render a rectangle at coordinate (X, Y) with a given width, height, and fill color is sent to
  the client. The client then executes the drawing order to produce the intended graphics result.
  In addition to defining how to encode common drawing operations, the Remote Desktop Protocol:
  GDI Acceleration Extension also facilitates the use of caches to store drawing primitives such as
  bitmaps, color tables, and characters. The effective use of caching techniques helps to reduce wire
  traffic by ensuring that items used in multiple drawing operations are sent only once from server to
  client (retransmission of these items for use in conjunction with future drawing operations is not
  required after the item has been cached on the client).
Zubok ★★★★★
()
Ответ на: комментарий от Napilnik

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

зато они откроют всё что могут это лучше чем ничего

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

Если на смену html красноглазики внезапно сделают какую-то хрень, то невписываемость этой хрени в файрфокс будет проблемой файрфокса?

Да, если это будет стандартом, это будут проблемы firefox. И если firefox это проигнорирует, то скатится в топку и потеряет пользователей.

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

>а что, собственно, плохого в сервере шрифтов?
Я могу что-то пропускать, но с каких пор в иксах появились шрифты в UCS-4? Это не говоря о нормальной поддержке лигатур, направления текста и прочих минимальных фичах.

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

> Да, если это будет стандартом, это будут проблемы firefox.

Только это не будет стандартом.

И если firefox это проигнорирует, то скатится в топку и потеряет пользователей.

И если файрфокс это проигнорирует, то мир останется сидеть на html. Вот в чём мысль, ну.

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

Во всяких виртуальных машинах проброс окон емнип через RDP и работает.

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

Х11 нужен! отвыкайте от стереотипности лоровских аналитиков.

и wayland тоже нужен.

не нужен только срач на эту тему, но без него видимо никак ибо 97%...

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

Только это не будет стандартом.

размышления на пустом месте

И если файрфокс это проигнорирует, то мир останется сидеть на html. Вот в чём мысль, ну.

Даже упоротые лисофилы перейдут на Chromium/Chrome/Opera и прочее, которые стандарт поддержат.

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

Разве там не навелосипедено по самое небалуйся?

Все бы такие велосипеды делали. Возможность прозрачной замены wm, панелек, трейеров, пейджеров, это очень и очень круто. NetWM, как стандарт, очень простой — оговаривает только разумный минимум операций, который должны поддерживать менеджеры окон. Собственно, поэтому и имеем такой чудовищный зоопарк приложений для управления окнами, *совместимых* между собой.

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

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

> размышления на пустом месте

20 лет существования html/http как бы намекают нам на его незыблемость. Такого числа исторически обусловленных архитектурных костылей нет даже в столь нелюбимом вами X11. Но замену ему не придумывают. Почему? Потому что инфраструктура.

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

>И если файрфокс это проигнорирует

У жырнолиса нет такого market share, как у IE в начале века, так что он не может диктовать условия

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

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

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

> У жырнолиса нет такого market share, как у IE в начале века, так что он не может диктовать условия

У жырнолиса нет, а у хрома и жырнолиса вместе есть.

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

Как уже говорил annulen, альтернативы html/http придумывали, но до реального внедрения не дошло, т.к либо спецификации пока в черновиках, либо на практике реализация идеи оказалась хуже самой задумки.
А это именно то, про что я выше говорил: Wayland не собирается сразу молниеносно заменять иксы. Его сначала обкатают. Попробуют убрать шероховатости. И если ничего не получится, то X'ы так и остануться. Но если Wayland оправдает ожидания и получится действительно стоящим проэктом со стоящей реализацией идей,то от Х будут отказываться, постепенно, поэтапно, плавно и эволюционно. О чём собственно говотрит презентация Мартина, с которой он выступал на Desktop Summit 2011 и на которую я выше давал ссылку.

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

Но велосипед != продуманность. Когда задним числом прикрутили что-то, значит изначально этого недодумали.

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

>Даже упоротые лисофилы перейдут на Chromium/Chrome/Opera и прочее, которые стандарт поддержат.

...если на этот стандарт перейдет вконтактик

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

Ох уж это слово — инфраструктура.

> ...если на этот стандарт перейдет вконтактик

То на вконтактик все перестанут заходить.

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

>Ты веришь разработчикам kde4?

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

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

КДЕ смогли быстро и решительно перейти на Qt4. Так что и с вейлендом у них всё тоже может быть быстро и решительно.

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

Ну… Из каноникла один человек занимается созданием сервера wayland внутри compiz. Остальные, видимо, рисуют темку и нескучные обои для следующей версии.

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

> Кстати, а разве большие исходники - это не признак больших возможностей, надежности и стабильного развития?
Нет, это признак раздутого кода.
http://doc.cat-v.org/programming/worse_is_better
http://harmful.cat-v.org/cat-v/unix_prog_design.pdf
---

DE, офисные пакеты

лучшие программы


Segmentation fault.

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

>КДЕ смогли быстро и решительно перейти на Qt4.

Это было уже после официального релиза, когда Qt4 уже во всю использовали в разработке приложений

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

Когда задним числом прикрутили что-то, значит изначально этого недодумали.

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

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

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

Этот рип уже 100500 лет как черновик. И т.к. HTML5 включает XML сериализацию, то… А на этот XHTML2 все производители браузеров положили большой болт (они и создали HTML5). Медленное развитие стандарта и саботаж XHTML'а Икрософтом также поспособствовали.

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

> Ты ещё и убунтоненавистник?!

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

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

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

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

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

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