UNIX альтернативная реализация иксам

wayland
framebuffer

http://www.y-windows.org/

>не вынося ничего в ядро

Уже выносят ) Тот же kms, page-flipping ioctl итд.

>IPC
Это будут трэшовые тормоза.

шареную память

X shared memory же.

Я имею в виду вызов процедур. Т.е сейчас чтобы нарисовать окошко надо отправить что-то чрезе сокет. Если убрать сокет (как узкое место), то надо придумтаь как взаимодействовать ;)

В wayland рисованием занимается сам клиент? А это не плохо для безопасности? Бажная программа может нарисовать черти что, или занять весь экран.

В иксах opengl рендерит клиент, к примеру.

> http://www.y-windows.org/
Там последняя новость датируется 2004 годом.

> А как еще реализовать подобное в юниксе/линуксе не вынося ничего в ядро?

А зачем не выносить в ядро работу с видео_устройством_?

Какие есть альтернативные архитектуры графической системы

win32

и где можно почитать об этом?

http://www.google.com

Нет, не работу с видео устройством, а более прикладные вещи, рисование окошек, скажем. Это же не жрайвер делает.

А разве он не шлет команды на сервер по протоколу glx ? как это будет работать, если клиент на другой машине стоит?

В win32 видео сервер находится в ядре как раз.

>рисование окошек
Рисованием занимается видеокарта же.

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

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

В винде его вынесли в ядро, и там хорошая производительность, т.к для обращения к графике юзаются быстрые АПИ вызовы.

В Иксах для обращения юзаются сокеты. Которые медленные.

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

Если сетевое взаимодействие нафиг не нужно? (кому нужно - поставят обычные иксы).

С чего ты вообще взял что сокеты (unix socketы, а не tcp/ip на 127.*, прошу заметить) являются узким местом?

Ну, не из серьезных исследований, жто точно ;)

А я не прав? Если нет, то где тогда узкое место?

> Многие ругают клиент серверную архитектуру иксов, дескать много ресурсов жрет.

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

> Ну, не из серьезных исследований, жто точно ;)

Вот с них и надо бы начать.

Да собственно я не критиковать иксы сюда написал. Мне было интересно послушать про альтренативные реализации.

Наверное, не совсем в тему будет, но мне доставляет безмерно вот такая штука: http://home.comcast.net/~fbui/

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

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

прям как в Plan 9 и Inferno... =)

Просто как shared library, с рядом syscall-ов для взаимодействия с драйверами, зачем какие то серверы придумывать.

Х вообще ужасный тормоз. Кто виноват - сейчас уже сложно сказать

http://www.jcraft.com/weirdx/

>http://www.jcraft.com/weirdx/

OMFG. X мало тормозят, так еще java надо добавить?

>...и где можно почитать об этом?

да хотябы про xv extension почитай на википедии. все вопросы отпадут.

Можно ещё исходники иксов почитать ;)

Если убрать сокет (как узкое место), то надо придумтаь как взаимодействовать ;)

а зачем его убирать? всё равно для localhost - это заглушка, а для распределённой работы по сети вроде пока ничего другого не придумали