Исправление Deleted, (текущая версия) :
Ну, если мы обсуждаем производительность иксов, и сравнивается два икссервера, то, наверное, реализация протокола икс11 в xorg.
Мы производительность только конкретного стека можем оценить, а не «X11» отдельно.
Конкретно в случае приложений мы имеем картину:
Приложение -> фронтэнд тулкита -> бэкэнд тулкита -> xlib -> IPC ядра -> фронтэнд X.org -> бэкэнд X.org -> аппаратные драйвера.
Вангую, что на 2D рендеринге через расширение XRender основная просадка будет в синхронном коде xlib, который принципиально не заточен пайплайнить запросы асинхронно. Сами иксы хоть запереписывайся в такой ситуации. Переписывать нужно тулкит, чтобы он не использовал xlib.
Еще в эту цепочку надо вставить обращения туда-обратно к композитному менеджеру через аналогичные звенья, если он используется.
Если использовать OGL, там цепочка короче, и участие xlib сведено к нулю, фактически она выкинута на мороз. Равно как и фронтэнд иксов. Композитор же либо отключается полностью для полноэкранных окон, либо, как в KDE, отключается по запросу приложения. Т.е. фактически имеем:
Приложение -> OGL-стек -> аппаратные драйвера.
Принципиальной разницы между иксами и неиксами быть не должно. Если она есть, надо разбираться.
Исправление Deleted, :
Ну, если мы обсуждаем производительность иксов, и сравнивается два икссервера, то, наверное, реализация протокола икс11 в xorg.
Мы производительность только конкретного стека можем оценить, а не «X11» отдельно.
Конкретно в случае приложений мы имеем картину:
Приложение -> фронтэнд тулкита -> бэкэнд тулкита -> xlib -> IPC ядра -> фронтэнд X.org -> бэкэнд X.org -> аппаратные драйвера.
Вангую, что на 2D рендеринге через расширение XRender основная просадка будет в синхронном коде xlib, который принципиально не заточен пайплайнить запросы асинхронно. Сами иксы хоть запереписывайся в такой ситуации. Переписывать нужно тулкит, чтобы он не использовал xlib.
Еще в эту цепочку надо вставить обращения туда-обратно к композитному менеджеру через аналогичные звенья, если он используется.
Если использовать OGL, там цепочка короче, и участие xlib сведено к нулю, фактически она выкинута на мороз. Равно как и фронтэнд иксов. Композитор же либо отключается полностью для полноэкранных окон, либо, как в KDE, отключается по запросу приложения. Т.е. фактически имеем:
Приложение -> OGL-стек -> ядро -> аппаратные драйвера.
Принципиальной разницы между иксами и неиксами быть не должно. Если она есть, надо разбираться.
Исправление Deleted, :
Ну, если мы обсуждаем производительность иксов, и сравнивается два икссервера, то, наверное, реализация протокола икс11 в xorg.
Мы производительность только конкретного стека можем оценить, а не «X11» отдельно.
Конкретно в случае приложений мы имеем картину:
Приложение -> фронтэнд тулкита -> бэкэнд тулкита -> xlib -> IPC ядра -> фронтэнд X.org -> бэкэнд X.org -> аппаратные драйвера.
Вангую, что на 2D рендеринге через расширение XRender основная просадка будет в синхронном коде xlib, который принципиально не заточен пайплайнить запросы асинхронно. Сами иксы хоть запереписывайся в такой ситуации. Переписывать нужно тулкит, чтобы он не использовал xlib.
Еще в эту цепочку надо вставить обращения туда-обратно к композитному менеджеру через аналогичные звенья, если он используется.
Если использовать OGL, там цепочка короче, и участие xlib сведено к нулю, фактически она выкинута на мороз. Равно как и фронтэнд иксов. Композитор же либо отключается полностью для полноэкранных окон, либо, как в KDE, отключается по запросу приложения. Т.е. фактически имеем:
Приложение -> OGL-стек -> ядро -> аппаратные драйвера.
Принципиальной разницы между иксами и неиксам быть не должно. Если она есть, надо разбираться.
Исправление Deleted, :
Ну, если мы обсуждаем производительность иксов, и сравнивается два икссервера, то, наверное, реализация протокола икс11 в xorg.
Мы производительность только конкретного стека можем оценить, а не «X11» отдельно.
Конкретно в случае приложений мы имеем картину:
Приложение -> фронтэнд тулкита -> бэкэнд тулкита -> xlib -> IPC ядра -> фронтэнд X.org -> бэкэнд X.org -> аппаратные драйвера.
Вангую, что на 2D рендеринге через расширение XRender основная просадка будет в синхронном коде xlib, который принципиально не заточен пайплайнить запросы асинхронно. Сами иксы хоть запереписывайся в такой ситуации. Переписывать нужно тулкит, чтобы он не использовал xlib.
Еще в эту цепочку надо вставить обращения туда-обратно к композитному менеджеру через аналогичные звенья, если он используется.
Если использовать OGL, там цепочка короче, и участие xlib сведено к нулю, фактически она выкинута на мороз. Равно как и фронтэнд иксов. Композитор же либо отключается для совсем полноэкранных окон, либо, как в KDE, отключается по запросу приложения. Т.е. фактически имеем:
Приложение -> OGL-стек -> ядро -> аппаратные драйвера.
Принципиальной разницы между иксами и неиксам быть не должно. Если она есть, надо разбираться.
Исходная версия Deleted, :
Ну, если мы обсуждаем производительность иксов, и сравнивается два икссервера, то, наверное, реализация протокола икс11 в xorg.
Мы производительность только конкретного стека можем оценить, а не «X11» отдельно.
Конкретно в случае приложений мы имеем картину:
Приложение -> фронт-энд тулкита -> бэкэнд тулкита -> xlib -> IPC ядра -> фронтэнд X.org -> бэкэнд X.org -> аппаратные драйвера.
Вангую, что на 2D рендеринге через расширение XRender основная просадка будет в синхронном коде xlib, который принципиально не заточен пайплайнить запросы асинхронно. Сами иксы хоть запереписывайся в такой ситуации. Переписывать нужно тулкит, чтобы он не использовал xlib.
Еще в эту цепочку надо вставить обращения туда-обратно к композитному менеджеру через аналогичные звенья, если он используется.
Если использовать OGL, там цепочка короче, и участие xlib сведено к нулю, фактически она выкинута на мороз. Равно как и фронтэнд иксов. Композитор же либо отключается для совсем полноэкранных окон, либо, как в KDE, отключается по запросу приложения. Т.е. фактически имеем:
Приложение -> OGL-стек -> ядро -> аппаратные драйвера.
Принципиальной разницы между иксами и неиксам быть не должно. Если она есть, надо разбираться.