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

> (зевая) В общем, оценок у вас нет.

(почёсывая левой лапой за правым ухом) так добудьте, опытным путём ;) они мне нужны/неубедительны, или вам?

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

вот вам менее абстрактные цифры:

1. An improvement of 62% for asynchronous display or 384% for synchronous display of images of a 100x100 size.
2. Scrolling a web page under MicroXwin is much faster and smoother.
3. There are only about 300 Kbytes of kernel memory in use by the kernel module. X.Org server, however, has a run-time memory usage of 12MB.
4. The smallest MicroXwin distribution can fit within 1 megabyte of disk space in contrast to the X.Org Server, which has a disk footprint of 1.8MB.

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

1. Не осилите даже без совместимости с Xlib - вероятность 60%
2. Бросите и не сможете довести до 100% рабочего состояния - вероятность 99%

А так вы не понимаете текующую проблему - в X.org по-прежнему туча операций выполняется на CPU, а в злосчастной Windows GDI появился в 1995 году.

Иксы становятся применимы в области множества маломощных терминалов же.

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

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

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

Для интелов же есть

> х сервер никому ничего не раздает по собственному почину, а тупо складирует события. а инфу запрашивают клиенты по мере надобности […]

ок. «раздаёт всем запросившим инфу клиентам» — так лучше?

> передвижение мышки на 3 пикселя никого не интересует.

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

а в негрософте об этом не знают, и даже под виртуалбоксом это всё-таки круг =)

Тоже замечал сию траблу в Гимпе, линия на экране появляется через доли секунды после того, как там мыша побывала. Кстати можете оценить какой тормоз вносит иксовый протокол простым опытом, сравните скорость работы кутишных прог с ключем -graphicssystem native и raster, первый способ рисует через xlib, второй просто отдает иксам готовые картинки. Но кстати тут один эксперимент провёл: попробовал через сеть подрубить кутишного клиента, так вот с raster тормоза дичайшие, а с native скорость не сильно упала.

Не надо зю. Запустите любой 'классический' de, типа wmaker и boxов, xlibовые родные программы типа xpdf, и них нигде ничто никак не тормозит. Что касается клиент-серверности - это прекрасная функция. И жаль что программы типа firefox не умеют запускаться by default на разных скринах. Мега функциональность такая как ssh -X пригождается очень часто - попробуйте её использовать и вам понравится.

Тормознутость же обеспечена меганеоптемизированностью тулкитов и многих графических программ, всякими dbusами и т.п.. Клиент-серверность рулит и не тормозит:

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.

Нет там никакого round-trip на unix сокетах в локальной системе. Синхронизированные request как известно тоже никто не шлёт кроме как в отладочных целях.

2. A context switch is required to move between executing client code and server code, if they are running on the same machine.

C учётом наступающеё многопроцессорности - это распараллеливание на клиента и сервера, good.

3. The client and server have to buffer and format commands and responses as per the X Window protocol.

Ну просто мегаdelay. Вопкуп полно говномегатормозоAPI типа XML или bdus, где такие 'затраты' воткнуты на каждом шагу ни никого не беспокоят - ключами являются asciiz строки, которые где-то ищутся, преобразуются сравниваются, XML выпарсивается в мегадерево где на каждый нод приходится по здоровенной записи и т.п. И все пользуются - ну что что птормозит - зато просто и понятно.

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.

ARM9 приходит и уходит, будет arm9 quad core, там такое разделение уёдёт только в плюс. вообще не аргумент.

Ох навалились злые дяди. Ну дайте пионерам поиграться! С вероятностью 99.99 ничего не выйдет из проекта. Но мы получим группу специалистов, которые себе набили шишки на низкоуровневом программировании графики - и, даст Бог, в следующем проект не станут наступать на разные уже наступленные грабли. Учебный это проект, для саморазвития тысызыть!

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

Очень часто использую три вещи:

1. Запуск приложений с другого компа export DISPLAY=myhost:0 ; application. Для этотого должен быть настроен X сервер на myhost (запуск без опции -nolisten tcp, настраивеатся в gdm/kdm/wdm/xdm) и сделан xhost +.

2. запуск приложений при помощи ssh -X. Сделал такой ssh и можешь просто так запускать любой аппликейшн на том компе, а вывод будет на твоём.

3. Запуск X -query otherhost , или просто 'логин в другую систему' в меню dm. для этого (через query), нужно тоже кой-чего поднастроить, но тогда работаешь в режиме тонкого клиентся - у на твоём сервере отображается полная сессия программ которые запущены на другом хосте.

4. Ну и X-Win32 канешна приходилось когда-то, но это offtopic и работеат он криво (тормозит).

а microxwin заценим :)

Ну это может быть просто показательным случаем, выявляющим какие-то структурные проблемы

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

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

> а для управления самим устройством веб морда больше рулит ибо трафика ещё меньше получается.
Молодежь... Man 3270

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

Толк будет, когда кто-то из производителей видеокарт додумается "засунуть" туда Х-ы.

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

>С моей точки зрения именно архитектура X.Org с ее многослойностью

Ты инженер-программист или гадалка?

Загубили образование... скоро мосты по прикидкам на глазок будут строить =(

oguretz> Собственно исследуется возможность создания легковесной альтернативы тормозной графической системы Linux.

У Linux графическая система - фреймбуфер. И он не такой уж и тормозной.

Но если говорить об X11, то эта оконная система вполне работала и на 386-х, и ещё на более слабых компьютерах.

Кроме того:

oguretz> высокая скорость работы <...> чтобы работали уже существующие DE

Тут видно оксюморон.

oguretz> БЕЗ клиент-серверной архитектуры

Такие уже имеются. Кстати, Qt это умеет. Но оно без клиент-серверной архитектуры нафиг не нужно - теряется огромная часть гибкости.

oguretz> часть функционала запихнуть в ядерный модуль

А вот за это УБИВАТЬУБИВАТЬУБИВАТЬ!!!!!

oguretz> Совместимость по драйверам, исключительно открытым (intel, radeon, radeonhd)

Эти дрова придётся с нуля переписывать тогда.

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

Greenday> Давно пора вычистить этот бсдшный код из линуксов.

Иксы к BSD имеют такое же отношение, какое они имеют к Windows.

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

Если переложить _всю_ графику на GPU, станет только тормознее из-за архитектуры современных видеокарт.

arsi> The GUI of the X Window System is slower partly because it is designed in a client-server architecture.

But modern GUI in X11 in many case slower thanks to modern desktop environments.

> БЕЗ клиент-серверной архитектуры

Каждый гадит в видеопамять и напрямую работает с устройствами? Какая феерическая идиотия! Даже в виндах архитектура GUI клиент-серверная, разве что общение идет через shared memory!

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

Ты неимоверно тупой дебил. Диспетчер окон, декоратор окон, компиз (который диспетчером окон и является), куча графический библиотек и т.д. - это НЕ ЧАСТИ X11.

Но раз ты такой тупой, ты начал гнать на саму основу - на X.org. Ты наверно ещё не знаешь, что X.org полностью модульный. А эта архитектура уже лучше, чем была у монолитного XFree86.

Запусти X11 c FluxBox - и удивись скорости работы. А потом удавись.

P.S.

Почему у тебя на настольном компьютере графическая подсистема тормозит, а у меня на КПК та же самая графическая подсистема летает?

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

Иксы как раз таки не тормозят. Тормозят кривые программы под них.

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

NX

Только дело такое, что оно совместимо с иксами не на все 100%. Но то, что от него требуется - работает.

Gorthauer> Ну есть одно место где это реально заметно - ресайз окошек

Зависит исключительно от реализации. Вон в Windows это тоже заметно на слабых машинах и при неустановленных дровах для видеокарты. Хотя графическая подсистема там по идее должна быть быстрее.

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

Можно пользоваться программами удалённо, к примеру. Это очень удобно. А если тонны софта поддерживаются X11 - это даёт огроменное преимущество линуксу. Но топикстартер хочет это важное преимущество убрать под корень, мотивируя это ускорением графической подсистемы. Вот только он этого таким путём не добьётся, так как не знает, почему наблюдаются тормоза. Он просто некомпетентный дурак, наслушавшийся где-то о том, что "у иксов тормозная архитектура".

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

Допустим, это так. Почему тогда курсор той же мышки не тормозит?

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

Вот так же решали эту проблему во времена Windows 9x. Причём заметьте, что топикстартер хочет подобную графическую подсистему.

Отсюда делаем вывод: что замена нынешней графической подсистемы на принципиально другую может изменить всё только в худшую сторону.

tempuser002> в X.org по-прежнему туча операций выполняется на CPU

Ну это уже проблемы конкретной реализации.

arsi> а в негрософте об этом не знают, и даже под виртуалбоксом это всё-таки круг =)

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

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

Учитывая растущее разрешение экрана на мобильных устройствах, а также наличие устройств с относительно большими габаритами экрана, таки фигню порешь. Ну и для embedded есть (или был) kdrive. Кроме того зачем на КПК и коммуникаторах есть VNC-клиенты?

> Допустим, это так. Почему тогда курсор той же мышки не тормозит?

а почему вы решили, что не тормозит? ;)

чисто визуально — да, не тормозит. хотя бы потому, что даже обычная мышка передаёт информацию об изменении координат чаще обновления экрана. но я говорю о том, что некоторым приложениям, вроде графических редакторов, информация о положении мышки/карандаша нужна гораздо чаще, и пофиг какая там развёртка монитора: если, к примеру, я решил расписаться с помощью планшетки, а на подпись у меня уходит ≈0.5сек, т.е. ≈30 «кадров», визуально я бы не заметил потерянных промежуточных значений, но подпись, состоящая из 30 отрезков, всё расскажет о недостатках архитектуры иксов ;) да, понимаю, что от примера с подписью отдаёт вакуумно-сферическим душком, но ничего практичнее сходу придумать не смог ;)

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

в данном случае — нет: планшетка подключена к винде@виртуалбокс как usb-устройство, с родными виндовыми дровами, родной input-подсистемой и т.п. да, винда там тормозит заметно, и быстро «нарисованный» на планшетке круг иногда начинает рисоваться в редакторе уже после того, как уберу «карандаш», и иногда даже визуально наблюдаю, как он постепенно отрисовывается — зависит выбранной кисти и загруженности хоста. но при всём этом не теряется ни один пакет от планшетки. результат, как говорится, налицо.

Оно?
http://live.gnome.org/GTK+/ClientSideWindows

>Такие уже имеются. Кстати, Qt это умеет.
Кстати, а реально ли собрать KDE + Qtopia?

Вы зря так агрессивно, я абсолютно чётко понимаю что даже здоровенный блоб драйвера nVidia не является, по сути, частью x.org, и о модульности x.org я тоже прекрасно осведомлен. Я имел ввиду архитектуру всего пользовательского интерфейса, которая, вобщем-то ничем, кроме основы не навязывается. Все было реализовано самым простым способом.

>Запусти X11 c FluxBox - и удивись скорости работы. А потом удавись.

Запустите винду или мак, и сравните со скоростью работы флюкса. Можете даже с частотой 75 герц кадры позаписывать - от щелчка до реакции интерфейса на него засечь их количество. В винде редко превышает 2, в маке редко превышает 3, флюкс реагирует на щелчок около 6-7 фреймов.

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

И поберегите нервы, и оскорблений лучше не использовать.

О данной конкретной реализации и речь.