История изменений

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

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

Программа, которая хочет чего-то там отобразить, должна:

1) понять, есть ли ей нужные расширения на сервере. Решить, чего делать, если их там нет.
2) всё, что она хочет, оформить в виде последовательности запросов, которые потом отправить на сервер.
3) получить от сервера и декодировать ответы.

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

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

История «победителя» может послужить прекрасным наглядным примером:

There are three very different libraries name Xft. The original 1.0 Xft library shipped with XFree86 4.0.2 and included a private configuration mechanism via the XftConfig file. For X servers without the Render extension, Xft 1.0 used core X fonts instead of client-side fonts. This was supposed to allow applications to code to a common API and run with all X servers.

Early in the deployment of Xft 1.0, it became abundantly clear that another custom X-specific font configuration mechanism was a really bad idea. Both KDE and Pango ended up stealing pieces of Xft to configure fonts. KDE created a GUI Xft configuration tool by stealing the XftConfig parsing code, Pango stole most of Xft so that the XftConfig file could be shared between the Xft and FreeType2 backends. Fontconfig was designed to solve both of these problems. The other problem in Xft 1.0 was the use of core X fonts when the server wasn't blessed with the Render extension. This meant that applications couldn't count on client-side fonts when using the high-level Xft APIs. As client-side fonts provide significant value beyond anti-aliased glyphs, it again became obvious that this design was flawed.

The Xft 1.0 API abstracted configuration details sufficient to permit a binary compatible version, Xft 1.1, to be developed which replaces the XftConfig configuration file with calls in to the Fontconfig library. Unfortunately, the Xft 1.0 API didn't sufficiently hide the rendering details making it impossible to provide for client-side fonts in servers without the Render extension. This means that Xft 1.1 shares font configuration, but isn't really usable on servers without Render.

The current version of Xft (2.0) provides a client-side font API for X applications. It uses FontConfig to select fonts and the X protocol for rendering them. When available, Xft uses the Render extension to accelerate text drawing. When Render is not available, Xft uses the core protocol to draw client-side glyphs. This provides completely compatible support of client-side fonts for all X servers. Drawing anti-aliased text with the core protocol involves fetching pixels from the destination, merging in the glyphs and shipping them back.

OpenGL'ные приложения работают в обоход иксов.

Wayland предлагает честную memory-модель доступа к формированию конечного изображения. Запрашиваешь себе буфер, рисуешь там, всё, что хочешь, даешь вейланду команду, что буфер готов к отображению. Чё и как ты там нарисовал - твои личные проблемы. Эта модель удобна тем, что легко совместима с GL/3D, что практически позволяет использовать один и тот же драйвер для GUI и 3D, как это делают сейчас последние версии венды и оэсыкса, и такая совместимость является одной из целей Wayland.

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

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

Программа, которая хочет чего-то там отобразить, должна:

1) понять, есть ли ей нужные расширения на сервере. Решить, чего делать, если их там нет.
2) всё, что она хочет, оформить в виде последовательности запросов, которые потом отправить на сервер.
3) получить от сервера и декодировать ответы.

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

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

История «победителя» может послужить прекрасным наглядным примером:

There are three very different libraries name Xft. The original 1.0 Xft library shipped with XFree86 4.0.2 and included a private configuration mechanism via the XftConfig file. For X servers without the Render extension, Xft 1.0 used core X fonts instead of client-side fonts. This was supposed to allow applications to code to a common API and run with all X servers.

Early in the deployment of Xft 1.0, it became abundantly clear that another custom X-specific font configuration mechanism was a really bad idea. Both KDE and Pango ended up stealing pieces of Xft to configure fonts. KDE created a GUI Xft configuration tool by stealing the XftConfig parsing code, Pango stole most of Xft so that the XftConfig file could be shared between the Xft and FreeType2 backends. Fontconfig was designed to solve both of these problems. The other problem in Xft 1.0 was the use of core X fonts when the server wasn't blessed with the Render extension. This meant that applications couldn't count on client-side fonts when using the high-level Xft APIs. As client-side fonts provide significant value beyond anti-aliased glyphs, it again became obvious that this design was flawed.

The Xft 1.0 API abstracted configuration details sufficient to permit a binary compatible version, Xft 1.1, to be developed which replaces the XftConfig configuration file with calls in to the Fontconfig library. Unfortunately, the Xft 1.0 API didn't sufficiently hide the rendering details making it impossible to provide for client-side fonts in servers without the Render extension. This means that Xft 1.1 shares font configuration, but isn't really usable on servers without Render.

The current version of Xft (2.0) provides a client-side font API for X applications. It uses FontConfig to select fonts and the X protocol for rendering them. When available, Xft uses the Render extension to accelerate text drawing. When Render is not available, Xft uses the core protocol to draw client-side glyphs. This provides completely compatible support of client-side fonts for all X servers. Drawing anti-aliased text with the core protocol involves fetching pixels from the destination, merging in the glyphs and shipping them back.

OpenGL'ные приложения работают в обоход иксов.

Wayland предлагает честную memory-модель доступа к формированию конечного изображения. Запрашиваешь себе буфер, рисуешь там, всё, что хочешь, даешь вейланду команду, что буфер готов к отображению. Чё и как ты там нарисовал - твои личные проблемы. Эта модель удобна тем, что легко совместима с GL/3D, что практически позволяет использовать один и тот же драйвер для GUI и 3D, как это делают сейчас последние версии венды и оэсыкса, и такая совместимость является одной из целей Wayland.