[не мое]Мысли вслух о протоколе X

pevzi> Согласен. Но это повлечет за собой, как я понял, и переписывание значительной части всяких GTK и Qt, а также видеодрайверов? Если с первым еще можно как-то справиться, то со вторым все гораздо сложнее.

Видеодрова как раз таки возможно и не придётся переписывать. И вот тулкиты - обязательно. И ничего страшного - первое время можно посидеть на X11, а X12 использовать как экспериментальную систему. Не сразу же на ядро 2.6 все перешли с 2.4 . Только придётся пару лет подождать после реализации X12 и переписывания под него тулкитов.

>> Расскажи мне, что не так с сетевой прозрачностью.

Я уже говорил. FreeNX с полноценной гномовской сессией работает быстрее, чем ssh -X

Походу ты плохо понимаешь, что такое протокол.

Причём здесь протокол? Я говорю про графику в линуксе вообще, в том числе про способы увидеть её по сети.

> Причём здесь протокол? Я говорю про графику в линуксе вообще

А, ну тогда конечно. Глобальные проблемы - это так круто.

То есть по-твоему проблем нет?

> То есть по-твоему проблем нет?

У меня - нет. Но я вижу, что у тебя их просто масса. Даже странно, зачем ты так мучаешься.

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

Точно. Примерно как вайн (: а в остальном PolarFox прав, чо.

Я не мучаюсь, я просто использую FreeNX для терминалки, потому что он показал себя лучше форвардинга иксов.

Ещё весьма посредственно сделаны проприетарные драйвера, временно сменил compiz на убогий metacity, так как в композитных менеджерах в этой связке иксы<->драйвер хреново работает BackFill Buffer.

> Я не мучаюсь

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

Ну дык в винде всё ещё хуже (правда в других аспектах), а на макось нету денег.

> твой план заставит немигрировавшие приложения (большинство приложений) тормозить в 2 раза больше.

большинство приложений

Да сфигали оно большинство-то? Большинство написано на GTK и Qt, которые по этому хитрому плану нужно переписать под X12.

>> твой план заставит немигрировавшие приложения (большинство приложений) тормозить в 2 раза больше.

Да сфигали оно большинство-то?

Что тебе непонятно в словах «немигрированные приложения»?

Это такая вариация «сперва добейся»? :)

> Благодаря Марку нас возможно уже не 1%, а 2%.

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

> Видеодрова как раз таки возможно и не придётся переписывать. И вот тулкиты - обязательно. И ничего страшного - первое время можно посидеть на X11, а X12 использовать как экспериментальную систему. Не сразу же на ядро 2.6 все перешли с 2.4 . Только придётся пару лет подождать после реализации X12 и переписывания под него тулкитов.

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

1) Создать X12, который бы учитывал все современные тенденции и не имел большей части недостатков X11;
2) Переписать GTK и Qt для работы с X12, таким образом дав возможность подавляющей части графического софта работать на новом протоколе;
3) Для остальных, еще не мигрировавших приложений создать слой совместимости.

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

Canonical обладает очень ограниченными ресурсами по сравнению с теми же RedHat и Novell. На исправление 12309, других кривостей и написание драйверов под всё, что имеет usb порт у них явно нет ресурсов.

> Что тебе непонятно в словах «немигрированные приложения»?

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

> Для остальных, еще не мигрировавших приложений создать слой совместимости

...или да, считать X12 экспериментальным, пока он не станет действительно юзабельным, как было с ядром (2.4 → 2.6).

> Где недостатки данного хитрого плана?

в нем не хватает пунктов:

4. ???

5. PROFIT

>Переписать GTK и Qt для работы с X12

Одного не пойму: нахрена к примеру тем же кутям иксы?

> в нем не хватает пунктов:

А если серьезно?

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

> А если серьезно?

А если серьезно, то X-протокол работает вполне нормально и проблем не вызывает. Его можно дорабатывать для случая узких каналов (NX), но для десктопа это не критично, да и для ЛВС тоже. Чистка протокола не даст большого профита (ну или ты можешь попытаться перечислить Top5 причин, по которым протокол следует сломать).

Еще можно предположить, что, может быть (всего лишь может быть) люди, которые занимаются X-сервером, компетентнее тебя, и знают, на какое направление тратить ограниченные ресурсы. И то, что их тратят на вещи вроде Gallium3D и Nouveau - это правильно.

>Эти претензии направляй к конкретной реализации.
Реализации чего?
Сейчас клиенты рисуют все сами, а серверу отдают картинку.
Это работает быстрее чем использование дочерних окон X Window (см. параметр Qt приложений --graphicssystem).
Как можно сделать ускорение на видюшке, если сервер получает уже готовую картинку, которую клиент нарисовал средствами процессора?

А есть реализации, где все хорошо?

Я пишу свой тулкит, позволю себе немного откомментировать:

Замути ли бы что нибудь новое на основе OpenGL, в смысле, чтобы вся отрисовка всех элементов делалась бы средствами OpenGL на видюшке.

А как быть, если приложение надо запустить в консоли? Причем не на VGA-шном говне, а на отдельном устройстве для отображения символов? или если у нас есть битмап, но размером скажем 120х60 пикселей? Видяшки то вообще может не быть... А как же речевые, вибрационные интерфейсы, азбука Брайля? Устройств ввода/отображения может быть очень много, всего и не описать, сейчас особенно это заметно на рынке мобильных устройств с их тачскринами, вибрациями, акселерометрами, мигающими панельками или часами-браслетами для них.

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

Ага, получаем win3,11 приложения, запущенные в 95 винде: половина кнопок в одном стиле, половина в другом, шрифты вообще едут и отображаются далеко не так, как было задумано авторами. Или как в вендоиксах: иконки чернобелые, антиалиасинга и в помине нет. Если подумать о скинованных интерфейсах, типа «гламурных часиках с тенью и полупрозрачностями», то тут вообще все плохо, отличия от теперешних иксов не будет.

И для работы по сети, как мне кажется, будет профит.

Несомненно, вот только если ты не обеспечишь потребность заказчика, то рискуешь нарваться на: «дайте мне канвас и сканкоды кнопок, дальше я сам» и хана твоей затее.

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

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

Как вариант - дать возможность создавать свои контролы (и это правильно!), да только вот в таких контролах может быть слишком много логики (реализуй мне виджет блендера, дабы можно было 3д-модельку крутить, все данные то загружены и уже на клиенте, в видяхе надо все-то координаты камеры поменять - по сети работа не нужна)

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

И вот захотел я в своем файловом менеджере сделать предпросмотр AVI-файлов... И шобы на превьюшках статистика отображалась с кривой-звука...

Ну, и стандартизированную иерархическую систему имен для ресурсов, типа /icons/actions/close и /widgets/menus/menu_item

лол, тут обычный hier не все осиливают, а так вообще неймспейсы будут нужны

>Пруф про графику в ядре.

Соломон и Русинович.

http://technet.microsoft.com/en-us/library/cc750820.aspx

MS Windows NT Kernel-mode User and GDI White Paper

Только тогда и нагрузка на карты была меньше, и сами карты были другие.

Тем кто думает, что в виндах и маке все чудесно от рождения - читать про gdi+ (скорость рендеринга текста), и вот эту серию статей:


http://arstechnica.com/reviews/01q2/macos-x-final/macos-x-1.html
http://arstechnica.com/apple/reviews/2001/10/macosx-10-1.ars
http://arstechnica.com/apple/reviews/2002/09/macosx-10-2.ars
http://arstechnica.com/apple/reviews/2003/11/macosx-10-3.ars

ну и далее.

> клиент-серверная графика на мобильнике это оверкилл

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

>Это когда при разрыве соединения убиваются все приложения на клиенте?

В чем здесь вина сервера?

> Запусти twm или fluxbox - и пойми, что графика в иксах не тормозная.

Запусти Opera 10.5x или links -g - и пойми, что графика в иксах не тормозная.

> Лучше всего просто напросто поменять протокол X11 на X12, который будет учитывать все современные технологии и тенденции.

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

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

ок, мы в 2010 году нашли 3 приложения и 5 оконных менеджеров. Все остальное тормозит. Как быть?

>> Это когда при разрыве соединения убиваются все приложения на клиенте?

В чем здесь вина сервера?

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

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

>Я пишу свой тулкит, позволю себе немного откомментировать:
Интересно, посмотреть на него можно?

А как быть, если приложение надо запустить в консоли?.....

Я не говорю про какую-то мега-глобальную штуку, которая заменит все и вся. Я говорю только про замену X Window на десктопе и близких к десктопу компьютерах. Естественно, 100% универсальности достичь не получится. Я не думаю, что какие-либо системы обеспечивают одинаковый интерфейс для работы с графикой и дисплеем брайля.

Ага, получаем win3,11 приложения, запущенные в 95 винде: половина кнопок в одном стиле, половина в другом, шрифты вообще едут и отображаются далеко не так, как было задумано авторами.

А сейчас в X-ах есть много тулкитов, и что? Мне кажется, что будет наоборот унификация внешнего вида.
Еще раз. Вот стартовала оконная система, первый клиент, пусть это будет какой-нибудь менеджер сессии (не важно, специальный клиент) заливает на сервер (или говорит где взять, тоже не важно) элементы GUI, т.е. кнопки, полосы прокрутки, и т.п. Все ресурсы имеют стандартизированные имена, по которым с ними можно работать.
Если клиенту надо несколько простых кнопок, то он сообщает серверу, что надо нарисовать /widgets/simple_button (может использоваться и ID, текстом я написал для наглядности) в таком то месте, такого-то размера (точно также как это делается сейчас в тулкитах, только вызывается функция, которая рисует кнопку, а тут -будет посылаться сообщение серверу). Если клиенту надо нестандартную кнопку, например в виде сердечка, то он ее рисует сам (в GTK и Qt сейчас так и есть, т.е. для клиента опять же отличия никакого), чтобы она была похожей на стандартные кнопки, клиент может получить цвета текущей темы, толщину бордюров и т.п.

Или как в вендоиксах: иконки чернобелые, антиалиасинга и в помине нет.

А что мешает делать АА на сервере?

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

Ну почему плохо? На примере часиков: клиент заливает текстуру циферблата, а потом рисует стрелки на отдельном слое. Таким образом он не посылает каждый раз картинку всех часиков. Как-то так...

Несомненно, вот только если ты не обеспечишь потребность заказчика, то рискуешь нарваться на: «дайте мне канвас и сканкоды кнопок, дальше я сам» и хана твоей затее.

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

Да, двигать кнопки - это плохо, масштабировать - еще хуже. Как минимум мы теряем лук-н-фил

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

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

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

И вот захотел я в своем файловом менеджере сделать предпросмотр AVI-файлов... И шобы на превьюшках статистика отображалась с кривой-звука...

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

> Ты хоть понимаешь, что для зачистки протокола понадобится переписывать мегатонны софта? Кто будет переписывать - ты с isden?

Зачем? Достаточно допилить гтк/кют, остальные сами прибегут

>>> Это когда при разрыве соединения убиваются все приложения на клиенте?

В чем здесь вина сервера?

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

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

X_server <-> tunnel_server <- network -> tunnel_client <-> X_client

>> Ты хоть понимаешь, что для зачистки протокола понадобится переписывать мегатонны софта? Кто будет переписывать - ты с isden?

Зачем? Достаточно допилить гтк/кют

Ненене. Давай _ты_ мне объяснишь, чего ради надо допиливать Gtk и Qt, и какой от этого профит пилильщикам. Пока что никто из отметившихся школьников мне этого никто объяснить не может. Может, у тебя получится?

остальные сами прибегут

Твой тулкит хотя бы XCB использует?

Как можно сделать ускорение на видюшке, если сервер получает уже готовую картинку, которую клиент нарисовал средствами процессора?

Ускорение операций Xrender/composite . Не настолько тривиально, как хотелось бы, настройка 3D-железа для «точечных» операций может занять много циклов процессора, шины.

Для ЦП писать некоторые алгоритмы проще, чем для даже нового ГП.

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

Там ещё тонкости со сбросом кэшей, атрибутами страниц и прочим. Выяснилось это только с приходом поддержки PAT, написанием ядерного менеджера памяти , т.е. сравнительно недавно. Да, и программирование GPU всё ещё новая тема, для большинства разработчиков. Так что даже если теоретически видеокарта может ускорить некий алгоритм - практически такой код в наших свободных ОС ещё не написан. Учим GLSL, и прочий C ...

>Много из того, что там написано носит маленький эволюционный характер, очень много вещей, которые носят, скажем, косметический характер.

pdf http://www.std.org/~msm/common/protocol.pdf не читали?

Это, скорее, выправка некоторых несколько слабых моментов, на которые еще мало, кто натыкался.

слабых моментов куча, просто «In some sense, this paper is too late- - -people writing X11 clients don’t want to rewrite code,
regardless of the benefits», обычная лень, X11 отстал и это нужно менять, а не потакать недальновидности его создателей

> Интересно, посмотреть на него можно?

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

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

Мы говорили о иксах и о замене для них.

Я говорю только про замену X Window на десктопе и близких к десктопу компьютерах.

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

Естественно, 100% универсальности достичь не получится. Я не думаю, что какие-либо системы обеспечивают одинаковый интерфейс для работы с графикой и дисплеем брайля.

Зато у иксов это почти получилось. Точнее, получился полигон для плагинов, которые могут работать вместе и не конфликтовать. Многие приложения сейчас выжили только благодаря тому, что на 90% пичкаются плагинами, а результат вроде как приемлем. Достаточно посмотреть на фаерфокс.

Еще раз. Вот стартовала оконная система ... заливает на сервер ... элементы GUI, т.е. кнопки, полосы прокрутки, и т.п.

Если клиенту надо несколько простых кнопок, то он сообщает серверу, что надо нарисовать /widgets/simple_button (может использоваться и ID, текстом я написал для наглядности)

Отличный, шикарный пример! А теперь мне надо нарисовать кнопку, которая может иметь красный, желтый или зеленый ободок, в зависимости от состояния приложения. В стандартных кнопках такого нет. Заливать свое? Тогда добро пожаловать в вин3.11 под вин95. Ну или в АкробатРидер под линупсом.

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

Привет хигу, привет нестандартным темам оформления, привет экранам телефонов (240х320 пикселей) и экранам проекторов (1920х1080)

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

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

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

А что мешает делать АА на сервере?

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

Ну почему плохо? На примере часиков: клиент заливает текстуру циферблата, а потом рисует стрелки на отдельном слое. Таким образом он не посылает каждый раз картинку всех часиков. Как-то так...

Верно, примерно так и сделано в моем тулките. Заливаются все возможные битмапы, а потом спрайтиками и рисуем нужное. Нечто подобное реализовано в RDP. А еще раньше это было сделано в NES на железячном уровне.

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

1. Если сегодня дать юзеру «получить канвас и кнопки», то через неделю будет десяток тулкитов, построенных поверх твоей технологии

2. Если заказчик хочет «красную кнопочку в углу, а вкладочки в тайтле», а ты этого не предусмотрел, то заказчику как правило плевать на все хиги и семантические интерфейсы, ему надо дать кнопочку.

3. Если клиент рисует сам - см.выше, возвращаемся к теням и бликам.

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

А без разницы. Откуда приложение знает, как масштабировать иконку или картинку? Какие размеры? Есть конечно экранное dpi, но на него все из покон веков клали мужской половой орган. Можно задать размеры в настройках программы, но тогда другие программы не подхватят ее и опять приходим к несогласованному лук-н-фил. И если даже мы знаем размеры, то как будем увеличивать? Линейно, с энерцией, или зигзагом? Еще надо помнить, что у юзера могут быть свои темы оформления, анимации интерфейсов могут быть тоже указаны и ты будешь выделяться из них.

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

Вот надо мне контрол для отрисовки гистограмм (как в гимпе или фотошопе), как мне его нарисовать, дабы он не выглядел говном в 100500 темах с KDE-look? Или сделаем «виджет для отрисовки гистограмм» стандартным и пусть авторы тем оформления с ним сношаются?

Маленькая подсказка: мне, как автору приложения, может быть совершенно пофиг на внешний вид контрола, зато юзер может захотеть его видеть в горизонтальном или вертикальном испонении, может его раскрасить по какому-то нужному ему профайлу, а то и вообще захотеть нанести свои метки на шкалу (например, при выводе графических файлов на TV надо соблюсти уровни 16-235 - было бы удобно видеть такие метки в гимпе)

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

А кто будет рисовать? Приложение? Сам тулкит? Приложение не знает тем пользователя, каких размеров ему рисовать (сгенерит ему тумбинашки 200х150 с текстом внизу, а файловый менеджер покажет 70х50, похерив весь текст и нарушив пропорции), сколько рисовать, ибо может в директории терабайт роликов - зря потратим ресурсы, ибо отображено может быть всего десяток миниатюр. Тулкит вообще не в курсе, как обрабатывать такие файлы, зато знает все о предпочтениях. Что делать? Городить свой протокол, только не от приложения к тулкиту, а от тулкита к приложению? Даже если мы в конечном итоге сгенерим картиночки, то как только я захочу сделать сортировку по длительности ролика (в минутах, а не байтах), то... Будем распознавать миниатюры? :)

> Ненене. Давай _ты_ мне объяснишь, чего ради надо допиливать Gtk и Qt, и какой от этого профит пилильщикам.

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

Твой тулкит хотя бы XCB использует?

Ну у меня и иксов нет...

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

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

> Я сказал это к тому, что если новая альтернатива будет показывать профиты

Ты не сказал главного - откуда эти профиты возьмутся. Впрочем, этого и следовало ожидать %)

> Я управлял асфальтоукладчиком

Ты еще ничем не управлял :D

> А вот Quasar на заметку. Вдруг он Ъ и не знает почему никто не хочет

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

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

> Ты не сказал главного - откуда эти профиты возьмутся. Впрочем, этого и следовало ожидать %)

Сам не знаю, но вот маки на сраной весе умудряются не тормозить...

> Ага. Но на самом деле есть и более серьезная проблема: новое поколение просто не врубается, что такое X Window System, и считает ее чем-то вроде GDI.

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

Я слышу разговоры «X sucks» уже лет 5 как минимум, но пока никто не начал делать замену, хотя эволюционных путей можно придумать как минимум парочку.

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

> То есть если тормоза отрисовки - в тулкитном говнокоде - то новый протокол улучшит ситуацию, нет?

Вот операсты пилят свой тулкит поверх х11, но все так летает, что кутя/гтк даже не тормозят, а стоят на месте. Не только в протоколе дело.

почему тогда на практике далеко не экономный? дизайн не соответствует действительности?

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

>> Я слышу разговоры «X sucks» уже лет 5 как минимум, но пока никто не начал делать замену, хотя эволюционных путей можно придумать как минимум парочку.

А как же вейленд?

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

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

«Мощно задвинул, внушаить» (c)

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