Альтернатива X.Org

Windows

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

Wayland. Похоже, описание с сайта тебе приснилось, и ты его сюда скопипастил. Только пара проблем... нет полной поддержки тулкитами и ДЕ всё ещё не адаптированы. А сам он работает. емнип, уже месяца как четыре.

Вы собрались лепить очередной Y ?
http://www.y-windows.org/

тучу раз об этом думал... может бы даже поучаствовал.

эдакий спортивный велосипед построить =)

> Вы собрались лепить очередной Y ?

Нет.

Давно мечтаю о подобной альтернативе...

Для начала, у вас есть численные оценки, какой вклад в тормоза вносится собственно Xorg-ом? По какой методике измеряли?

Есть подозрение, что сделав мегабыструю замену для Xorg, вы повысите скорость работы графической системы в целом процентов этак на 5. Бугага?

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

1. Очередной Y?

2. Фреймбуффер вам не нравится?

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

Есть задачи, есть софт и есть железо. И приоритет растёт(для большинства способных что-то изменить людей) не с конца, как некоторые бездельники считают.

Так что я бы просто купил более мощную видеокарту.

//Кстати, когда в открытых дровах ну хоть версия 2.1 OpenGL'я появится?

>Есть подозрение, что сделав мегабыструю замену для Xorg, вы повысите скорость работы графической системы в целом процентов этак на 5. Бугага?

+1

Для более быстрой графической системы нужно в первую очередь пилить видео-драйвры и перекладывать все графические расчеты на GPU.

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

Чуть не забыл: автор Wayland'а предложил запускать Иксы в отдельном окне. Для совместимости с ещё не адаптированным софтом. Правда не знаю как там сейчас...

//Где стабильные открытые дрова, с полной поддержкой возможностей железа? Правильно, и несколько лет не будет.

> какой вклад в тормоза вносится собственно Xorg-ом?

The GUI of the X Window System is slower partly because it is designed in a client-server architecture. X is separated into two parts, the X server and multiple X clients. The X server is a single-threaded process which handles the requests from X clients to perform access and control to graphical and input devices. Some drawbacks have been noticed in this kind of configuration:

1. There is a round-trip delay time between client and server (latency rather than from the protocol itself) when a synchronized request is issued.
2. A context switch is required to move between executing client code and server code, if they are running on the same machine.
3. The client and server have to buffer and format commands and responses as per the X Window protocol.
4. On processors with virtually addressed cache, such as ARM 9, context switching between an application and the X server results in a cache flush, further degrading performance.

Due to higher CPU usage, these drawbacks make the X Window System an unresponsive and slower GUI framework to the user in comparison with other windowing systems such as Microsoft Windows (up to and including Windows XP) and Quartz.

(source)

Прекрасно. А где же численная оценка и методика измерения?

Может через четыре года мы увидим 16-ти ядерные процы, и поголовный переход открытых проектов на использование OpenCL. И не будет особой разницы между процом и видеокартой...

> А где же численная оценка […]?

Benefits Of MicroXwin

[…]

Snappy GUI - MicroXwin has 2X times faster graphics, faster event handling, low latency and low round-trip delays.

Lower Memory Usage - MicroXwin's kernel based X server uses < 1/2MB versus 19MB used by Xorg server on Fedora 7 distribution.

> А где же […] методика измерения?

хз, а вам какая нужна/устроит?

ИМХО это бред. Какой смысл в многопоточном сервере, если в регистры и память видяхи нельзя писать параллельно? Это только лишние накладные расходы на синхронизацию потоков. Мультипоточной должна быть xlib, что сделано уже сто лет назад.

а ещё через десяток лет kde6 будет использовать нейроимплант в качестве бекенда для отрисовки, а не какие-то там иксы ;)

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

>Есть подозрение, что сделав мегабыструю замену для Xorg, вы повысите скорость работы графической системы в целом процентов этак на 5.

Вы меня натолкнули на пару мыслей.

Есть такие подозрения. Равно как и подозрения, что допустим графическая система с интегрированным GTK- (ну или Qt-) API, плюс аппаратное ускорение будет работать очевидно быстрее ныне существующего монстра. Пусть что-то будет в нее жестко вшито - тот же window manager, display manager, но работать оно просто обязано быстрее. Это я к тому, что наверно не конкретно в X.Org дело, а действительно в архитектуре всей графической подсистемы. Наверное как-то так.

И опять в этом треде описали Wayland. Ну, что нужно спросить, раз нагуглить не удаётся?

>А ты представляешь себе задачу, эмуляции xlib на этом кастрированном сервере?

Ты ничего не путаешь? А не на клиенте она нужна? Для генерации команд Х-ам?

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

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

> И опять в этом треде описали Wayland.

А помоему описали как раз Windows.

Ну да ладно, X11 уже есть и работает (и тормозоит не сильнее Windows Seven), и при этом отлично масштабируется (сколько ждать аналогов randr в этом вашем ваиланде?).

И для твердящих про сетевую архитектуру: на локалхосте иксовые клиенты к серверу не по tcp/ip соединяются. В любом ваиланде будет полный аналог сетевой архитектуры, окна, которые рисуются в неком общем пространстве различными процессами.

Так что такой велосепедизм не нужен.

Не нашем Вайланде :) Я только за стабилизацию и адаптацию Иксов к многоядерным системам.

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

> хз, а вам какая нужна/устроит?

Не достаточно оценки в духе "Over 9000", нужно разобраться, как она получена. Может быть, измерено было совсем не то, что представляет действительный интерес?

>>//Кстати, когда в открытых дровах ну хоть версия 2.1 OpenGL'я появится?
Уже есть в интелах, даже lightmarks пускается, правда показывает гордые 7-10 FPS
Вообще да, есть же Wayland display server, но его кажется не оч активно пилят, ежели присоединитесь к ним, то можно буит ускорить процесс. Наверняка там пока нету ни рандра ни мультипоинтеров и тому подобных вещей. А в качестве адаптации тулкитов, то всеравно современные тулкиты скоро через openGL будут рисоваться, поэтому в граф системе буит достаточно оставить только его, а старый x11 пустить в режиме эмуляции, ну грубо говоря сделать тоже самое, что сделал Яббл. И в любом случае эта замена скорее всего +50% к скорости не даст, максимум процентов 10-15, главное что ресурсов она меньше жрать буит и это значит мобильные устройства будут жить дольше. А ежели охота ещё большей скорости то пилите видеодрова, главный тормоз сейчас именно они

Да... иксы порой жутко тормозят, они не могут просто БЫСТРО работать?

>>версия 2.1 OpenGL'я

>Уже есть в интелах

Ты точно не о swrast Mesa'вском? Не видел(на опеннете) в анонсе дров 2.8 инфы об этом.

Кстати по ходу дела Wayland успел скончаться уже
http://cgit.freedesktop.org/~krh/wayland/

Смотри гуглогруппу - он говорил что работа окончена, осталось пропихнуть патчи для gtk+ и qt с прочими в апстрим.

>Ты точно не о swrast Mesa'вском? Не видел(на опеннете) в анонсе дров 2.8 инфы об этом

sauron@littlejonh ~ $ glxinfo |grep Open
OpenGL vendor string: Tungsten Graphics, Inc
OpenGL renderer string: Mesa DRI Mobile Intel® GM45 Express Chipset GEM 20090712 2009Q2 RC3
OpenGL version string: 2.1 Mesa 7.6-devel

В 7.5 месе точно такая же версия, правда с 7.6 версией Лайтмаркс почему то виснет ежели в полноэкранном режиме пускать

>Смотри гуглогруппу - он говорил что работа окончена, осталось пропихнуть патчи для gtk+ и qt с прочими в апстрим.
Блин а я уж расстроился... Кстати а кто-нить пакеты с ним собирал уже? А то мне как то геммороится с накатыванием патча на ведро, поиском кучи зависимостей, еблей с autotoolsами неохота заниматься.

> нужно разобраться, как она получена.

подозреваю, что с помощью time(1) и ps(1) %)

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

Круто. Нужно накатить на ноут.

Это отнимает сотые доли процентов от времени, человек не может нажимать кнопки с частотой мегагерц.

>Кстати а кто-нить пакеты с ним собирал уже?

Я не видел. Но у разработчиков(несколько веток: qt, clutterm gtk+, egl) точно есть полурабочие пакеты ;)

>Это отнимает сотые доли процентов от времени, человек не может нажимать кнопки с частотой мегагерц.
Ну есть одно место где это реально заметно - ресайз окошек, там частота обновлений нужна оч большая и видно что иксы с ней хуже справляются, чем например directFB, ну и как я уже говорил это энергосбережение в тех случаях когда иксы крутятся например на телефонах. Тут то Вайланд себя и может проявить

Как впрочем и велосипед от Гугла.
/me прогнозирует, что к тулкитосрачам, DEсрачам, WMсрачам прибавятся ещё Window system срачи.

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

Ресайз окошек делает клиент, получив событие от сервера. А клиент работает через мультипоточную хlib.

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

(зевая) В общем, оценок у вас нет. Есть какая-то абстрактная цифра "в 2 раза", и не менее абстрактные предположения про time(1). Не убедительно.

вообще, кто-то объяснит, какой толк у иксов от клиент-серверной архитектуры?

> человек не может нажимать кнопки с частотой мегагерц.

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

>>Это отнимает сотые доли процентов от времени, человек не может нажимать кнопки с частотой мегагерц. Ну есть одно место где это реально заметно - ресайз окошек, там частота обновлений нужна оч большая и видно что иксы с ней хуже справляются, чем например directFB, ну и как я уже говорил это энергосбережение в тех случаях когда иксы крутятся например на телефонах. Тут то Вайланд себя и может проявить

Решил это проблему намного проще - при ресайзе отображаются только рамки :)

А если использовать компицы всякие, что тогда чики-пуки.

Можно ещё текстуру растягивать окна, тоже всё чики пуки буит. Но это не решение проблемы а так скорее способ её обхода. Просто именно ресайз наиболее наглядно показывает проблемы в иксах, и если его полностью побороть, дабы окошки меняли размер по крайней мере не хуже, чем в Макоси, то значит можно сказать что проблемы иксов с производительностью 2D по большей части перебороты

>Можно ещё текстуру растягивать окна, тоже всё чики пуки буит. Но это не решение проблемы а так скорее способ её обхода. Просто именно ресайз наиболее наглядно показывает проблемы в иксах, и если его полностью побороть, дабы окошки меняли размер по крайней мере не хуже, чем в Макоси, то значит можно сказать что проблемы иксов с производительностью 2D по большей части перебороты

Это просто глупо - делать радикальные замены из-за одной проблемы, которая и не проблема вовсе. Кому оно мешает? Тебе не все ли равно, растягивается текстура или окно? Есть куча других преимещуств. Так что графика в ядре сакс. Макось не показатель.