Разница xlib и xcb

xcb это тонкие обёртки над отправкой/приёмом из x11-сокета. Скорее всего никакой пользы ты от них не получишь.

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

ICCCM тут не особо при чём. Это само по себе надстройка над базовым функционалом xlib (и кстати необязательная к поддержке софтом), это не часть собственно протокола, а рекомендации по его применению. Сравнение xlib vs xcb на неё не особо влияет.

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

Если проводить очень грубую аналогию, то разница как между OpenGL и Vulkan. Первый имеет ниже порог входа, но плохо дружит с многопоточностью и микрооптимизациями (из-за того что абстракция достаточно толстая, проблематично контролировать что там под капотом происходит), второй требует около тысячи строк на Hello World с треугольником (для сравнения OpenGL даже с шейдерами укладывается в <300), зато можно выжать максимум из железа.

Короче, если пишешь свой GUI фреймворк или оконный менеджер, то XCB must have. Если тебе нужно просто пару кнопок показать, то Xlib скорее всего предпочтительнее. Впрочем, для пары кнопок обычно удобнее использовать Qt/GTK или на худой конец SDL.

XCB «современнее», потому что по факту сейчас уже никто не пишет прикладной софт на голом API X11, а пользуются фреймворками и прослойками. А уже они, в свою очередь, используют XCB под капотом (потому что он реально лучше для фреймворков за счёт большего контроля). В итоге получается, что новая кодовая база поголовно использует XCB, а на Xlib сидит старый софт написанный без фреймворков.

Xlib тоже не так что бы прямо синхронный. Просто там асинхронность немного спрятана.

Про xcb для фреймворков согласен, но автор вряд ли пишет фреймворк, он же только начал изучать.

сейчас уже никто не пишет прикладной софт на голом API X11, а пользуются фреймворками и прослойками.

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

XLib не нужна вообще, если не занимаешься retro-кодингом

это уже манипулятивное заявление, не надо.

Назови прикладные программы, у которых первый релиз вышел в последние 5 лет, они не являются нишевым оконным менеджером (для которых на самом деле XCB предпочтительнее, но у авторов была цель выкатить MVP минимальными усилиями) и они используют Xlib.

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

Но дело не в этом. По статистике, наверно, и правда фреймворками пользуются чаще, но для категоричного заявления «никто не пишет» этого явно недостаточно. Кроме того, у этого заявления, ввиду его (ложной) категоричности, получается эмоциональный подтекст вида «не трогай это старьё», тоже обманывающий, почему я и сказал что заявление манипулятивное.

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

Насколько сильно у них отличается API?

все намного проще - xcb он сгенерированный, поэтому документации нет, API практически не отличается (если писал на XLib и у тебя работает мозг), все те же самые функции, когда это понимаешь достаточно доки https://xcb.freedesktop.org/manual/modules.html

асинхронщина там по одному сценарию различие в обработке ошибки (XLib возвращает сразу) - xcb основной API с суффиксом xcb_xxx_checked возвращает cookie, статус выполнения которого (и ошибку) можно проверить позже через xcb_request_check, и есть запросы которые должны вернуть результат это с суффиксом xcb_xxx_reply, и есть методы без таких проверок xcb_xxx - где если будет ошибка, то она вывалится в event цикл.

команда xcb заявляет что это быстрее xlib, и уже с этим никто не спорит. Thread safe. Но если делать по варианту _checked получаешь как Xlib

проблема с xcb - если пишешь все вручную cheched/unchecked/reply это также много ненужного повторяющегося кода, потом ты начинаешь подтягивать template/define и получается более менее.

XLib возвращает сразу

В большинстве случаев - нет. Сразу возвращает только XSync и ещё несколько синхронных функций, всё остальное асинхронное.

команда xcb заявляет что это быстрее xlib, и уже с этим никто не спорит

Нет никакой «команды xcb». Насчёт «быстрее» - сомнительно.

За развитие проекта XCB (X protocol C-language Binding) отвечает сообщество разработчиков. Тесты все были еще с тех времен. Сейчас ты своим категоричным нет зачем то влазишь в бутылку, из которой потом не вылезешь.. а пробкой будет - XDisplayLock/XDisplayUnlock vs Thread safe. И разрабы XLib давно мигрировали на xcb, это уже мюзле)

XCB асинхронный и с его помощью проще писать более производительный код за счёт того что тебе не нужно ждать ответа на один запрос

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

Всё правильно сказали, но смысла нет, wayland наступил.

то разница как между OpenGL и Vulkan

Я вообще не в теме, но по описанию выглядит так, что Vulkan мало отличается от ручной записи байтов в память. Это точно ФРЕЙМВОРК?

Точно!

но смысла нет, wayland наступил.

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

Подводя итоги:

1. xcb не современный, это лишь сгенерированный API из описания протокола;
2. xcb более многословный, но это компенсируется макросами;
3. xcb более приближен к протоколу;
4. xcb не быстрый сам по себе, он просто не скрывает управление за API, поэтому ты его должен будешь реализовывать сам (компенсируется макросами?).

До сих пор некоторые люди сидят на Windows XP и делают софт/прослойки совместимости для него. От X11 никто не откажется разом. Некоторым это попросту не нужно.

X11 в данный момент более практичный выбор, т. к. 100% запустится везде и возможности WM/композиторов везде одинаковые. Можно привести еще тейков, но основное - стабильность и совместимость

Изначально в XLib была своя реализация клиентской части X-протокола. Сейчас примитивы XLib это просто не очень толстая обёртка вокруг соответствующих функций xcb. На клиенте XLib создаются GС и других объекты XLib, в которых храняться соответствующие ID и ещё что-нибудь для удобства.

The contents of a GC are private to Xlib.

Xlib implements a write-back cache for all elements of a GC that are not resource IDs to allow Xlib to implement the transparent coalescing of changes to GCs.

Современная XLib по отношению к xcb подобна MFC по отношению к win32. Можно пользоваться обёртками, можно вызывать функции напрямую.

Но если что-то делается в обход X11-протокола, то в xcb этого, естественно, нет.

Насколько сильно у них отличается API?

Старый tutorial никто не упоминал?

https://xorg.freedesktop.org/archive/current/doc/libxcb/tutorial/index.html

PS структуры из

#include <xcb/xcb.h>

можно попытаться использовать, чтобы самому писать/читать в/из сокета.

смысла нет, wayland наступил.

Да хоть бы и наступил. Что если нужна программа одинаково хорошо работающая на больше чем одной реализации Вялого? Какие есть варианты кроме Xwayland и wine?

Какие есть варианты кроме Xwayland и wine?

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

написание программы под иксы делает ее более переносимой.

А написание на Qt позволяет переносить её на всевозможнные оффтопики и встроенные платформы. Даже на те, которых во время написания ещё нет.

Сказка про белого бычка wayland-edition:

— А как у вас реализовать то-то и сё-то?
— А вот есть протокол специальный!
— А как сделать, чтобы везде работало?
— А нехрен использовать левые протоколы!
— А как у вас реализовать то-то и сё-то?
— А вот есть протокол специальный!
...

Ну а как ещё делать, если есть по-сути 3,5 крупных игрока (GNOME, KDE, wlroots и берём за половину gamescope by Valve), которые хотят развивать свой проект по своему, но пока хоть как-то ДОГОВАРИВАЮТСЯ об итоговых конечных протоколах, которые работают у всех. Ну или будут работать (вон в новом Гноме ещё парочку реализовали).

С другой стороны, то-же KDE нарожало своих кастомных, которые нужны только ей, и если автор приложения на них завязался, то кто ему доктор: пусть пишет fallback, благо о наличии/отсутствии протокола можно прямо при инициализации узнать.

С точки зрения переносимости лучше взять SDL, если хочется сам UI делать с нуля или Qt/GTK, если хочется готовых компонентов. Количество платформ будет больше (и выходить далеко за рамки X11 и Wayland), а количество трудозатрат на работу с оконной подсистемой меньше хоть по сравнению с Xlib, хоть по сравнению с xcb.

Во-первых, ни Vulkan, ни OpenGL не являются фреймворками, это графические библиотеки достаточно слабо влияющие на структуру прикладного кода. Фреймворк не случайно переводится как «каркас», он задаёт структуру приложения (например, в Qt ты будешь наследовать классы от QWindow, QWidget и QObject, использовать сигналы и слоты при реализации бизнес-логики и т. п.).

Во-вторых, Vulkan нужен для того чтобы не перекладывать байтики не просто вручную, а чтобы не перекладывать байтики вручную уникальным для каждой видеокарты способом.

Ну а как ещё делать,

Сидеть на иксах до талого.

которые работают у всех

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

KDE нарожало своих кастомных

Полагаю не без причины.

X11 в данный момент более практичный выбор

для дома или интерпрайза ?

знаю что у XLibre знатно подгорает с Xcb😊

Для всего.

Сидеть на иксах до талого.

Ну, нужное мне работает. Я переключился. Может кому и нет, не осуждаю.

Полагаю не без причины.

Ну, как-бы, никем не возбраняется. Понятное дело, что и работать это будет только в KDE.

Для всего.

слишком категорично, не соглашусь, например поставив себе кубунту 2604 я имею более плавный gui без дерганий и фликов на вейланде

А у меня нормальный гуи на дебиане 11.

чтобы не перекладывать байтики вручную уникальным для каждой видеокарты способом

Я понял, мир захватили погромисты БК0010 с помощью оператора POKE(x,y).

А написание на Qt позволяет переносить её на всевозможнные оффтопики и встроенные платформы.

Это не только Qt позволяет. Есть и более простые в использовании но не рекламируемые столь активно средства. Хотя для встроенных компов Qt всё же весьма тяжеловат. Ну и понятно что Qt под иксами тоже работает.

Ну, нужное мне работает. Я переключился.

Я прямо сейчас в сессии wayland Gnome 42.9. Есть неприятный глюк с Edge и панелькой задач после login’а. В чём дело, как чинить? Да хрен знает, переключусь в X11, там всё работает.

Ну, как-бы, никем не возбраняется. Понятное дело, что и работать это будет только в KDE.

Ну да. Заложился на KDE/Wayland — получи проблемы на Gnome. Заложился на Gnome/Wayland — получи проблемы на KDE. Используешь X11 — всё работает везде.

Используешь X11.

Заложился на расширения … а хз, есть они и какой версии. Работает, потому что это не трогали с прошлого десятилетия. Поэтому иллюзия стабильности есть.

Заложился на KDE/Wayland … Заложился на Gnome/Wayland …

Вывод: нужно кастомное расширение - делай fallback. Всем лень, ну а что делать.

Поэтому иллюзия стабильности есть.

Иллюзия, это когда кажется, что оно есть, а на самом деле его нет. А когда тридцать лет что-то работает и не ломается, это не иллюзия. Это идеал.

делай fallback.

Круто. Половину DE ещё напиши, чтоб получить тот же результат, который в иксах есть из коробки. Потому что только тех, кто любит труд, пионерами зовут, так-то.

А когда тридцать лет что-то работает и не ломается, это не иллюзия. Это идеал.

Ну, во-первых, не тридцать уж. Во-вторых, ну правильно - никто сильно не трогает, нечему и ломаться. Стоит хоть как-то тот копролит серьёзно тронуть, всё нахер разваливается.

Половину DE

Чтобы вывести уведомление нужно полDE написать? Ну или, например, в 10 строчек подключить libdecor, если жить не быть захотелось декораций?

И да, пользоваться Qt/GTK/etc., где детские болячки уже порешали. Разраб выбрал путь страданий и кастома (костылей вокруг иксов, привет KiCAD-у, тоже касается), пусть делает кастом, страдает и не выёживается :)

Ну, во-первых, не тридцать уж.

Больше сорока уже. Спасибо, что напомнили.

Стоит хоть как-то тот копролит серьёзно тронуть, всё нахер разваливается.

С этого места по-подробнее, пожалуйста.

Чтобы вывести уведомление нужно полDE написать?

Сами писали «KDE нарожало своих кастомных» … «и работать это будет только в KDE». Никто за язык не тянул. Вот, чтобы это работало вне КДЕ и нужно написать свою реализацию кастомных КДЕшных расширений вэйланда.

И да, пользоваться Qt/GTK/etc.,

Туда уже засунули кастомные кде-шные протоколы? И эти люди ругали архитектуру иксов!

С этого места по-подробнее, пожалуйста.

Тебе нужно расширение Xrandr в твоем сетапе X-сервера его нет или версия его ниже чем надо (пример теоретический). Как я должен об этом узнать и мои дальнейшие действия? Падение с BadWindow - это не действие.

Вот, чтобы это работало вне КДЕ и нужно написать свою реализацию кастомных КДЕшных расширений вэйланда.

Или можно сразу узнать что их нет и не использовать.

Не будет GNOME в обозримой перспективе поддерживать серверные декорации: используй libdecor (целых 10, вроде, строчек кода - это трагедия) или просто не делай их, если нет протокола (отрази это в справке, например). И так по всему кастому.

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

Нет. Там уже за вас сделали все fallback-и и спроектировали консистентный API. Бери и пользуйся.

Тебе нужно расширение Xrandr в твоем сетапе X-сервера его нет

Куда делся? Враги украли? Интервенты? Давайте разбираться как мы оказались в такой ситуации.

мои дальнейшие действия?

Обновить документацию.

Или можно сразу узнать что их нет

Как, например? Гипотетически, вот я пишу программу и хочу, чтобы работала на максимальном количестве окружений. Причём не только сейчас, но и в будущем. Мне в хрустальный шар смотреть или таро раскладыать?

Не будет GNOME в обозримой перспективе поддерживать серверные декорации: используй libdecor

Это мне по каждому wayland композитору нужно вот так пройтись? Круто. Замечательно. Всегда мечтал.

Нет. Там уже за вас сделали все fallback-и и

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

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

Куда делся? Враги украли? Интервенты? Давайте разбираться как мы оказались в такой ситуации.

Вам расширения не нравятся. Это тоже расширение. Причем в формате отдельной библиотеки. Оно может быть, может нет. Версионирование в X11 не предусмотрено.

Обновить документацию.

В рантайме мне это чем поможет?

Как, например?

Разберитесь с инициализацией wayland приложения для начала. При инициализации мы сразу получаем весь ростер протоколов, которые поддерживает композитор.

Мне в хрустальный шар смотреть или таро раскладыать?

Достаточно по ростеру пройтись.

Это мне по каждому wayland композитору нужно вот так пройтись?

Т.е. как это работает не в перепевке Рабиновичей вы не в курсе? Ок.

Вот проектируют что-то типа велосипеда

Просто до этого был один выживший сервер (потому что остальные сдохли, а они были), к которому боялись сильно прикасаться, потому что ну его нахер. От этого КАЖЕТСЯ, что 40 лет было всё стабильно и радостно. Теперь этих серверов 3 с половиной (не берём всякую мелочь, которая порой и самим создателям не сильно нужна) - трагедия/паника/армагеддец (нет).

...а раньше все делали. А под Direct3D до сих пор все делают. Не, я понимаю, когда Nintendo на заранее планово слабом железе... Но тут-то что за олимпиада инвалидов?

Тебе нужно расширение Xrandr

Ну, по-хорошему, не особо то и нужно. Я не вращаю экраны без перезагрузки, например. А вот выпиливание bitmap шрифтов оказалось плохой практикой (в оффтопике вот не выпилили)

Вам расширения не нравятся

Расширения мне нравятся. Мне не нравится, что у каждого композитора свой несовместимый набор расширений.

Разберитесь с инициализацией wayland приложения для начала.

Пардоньте, костыли нужно добавлять в приложение до того, как оно где-то запустилось, ещё на стадии разработки.

Просто до этого был один выживший сервер

Ну и отлично. В чём проблема? Зачем стали ломать?

От этого КАЖЕТСЯ, что 40 лет было всё стабильно

Т.е. на самом деле было нестабильно, да? Постоянно выходили ломающие обновления, цвёл зоопарк несовместимых реализаций и т.п.?

Теперь этих серверов 3 с половиной

Стало в 3.5 раза хуже.

не берём всякую мелочь

К слову под Х11 всякая мелочь чувствовала себя великолепно. У всех wm вплоть до извращений вроде Emacs X Window Manager есть стабильная общая основа, которая позволяет им всем работать. Разработчику приложений вообще не нужно заморачиваться под каким wm его программа будет работать. Никто даже не думал, что с этой стороны могут быть проблемы. И вот, здавствуй жопа новый год, теперь у нас гора протоколов, намазанная на разные несовместимые реализации. Кушайте, не обляпайтесь.

Мне не нравится, что у каждого композитора свой несовместимый набор расширений.

X11 by design. Опять же вы пишете с позиции Xorg. Но он исторически НЕ был один. Он был последний из выживших.

ещё на стадии разработки

Предполагается, что тебе туда вообще лезть не надо, если ты не автор Qt/Gtk/SDL и т.д.

Зачем стали ломать?

Потому что упёрлись в его ограничения. Несколько лет думали, как с этим жить. Придумали wayland, другого не придумалось.

Т.е. на самом деле было нестабильно, да?

Мне нужно XFree86 вспоминать чтоли? Тоже X11. Последний релиз в 2008 был, между прочем. Давай, проверь стабильность. Запусти на нём современный десктоп.

К слову под Х11 всякая мелочь чувствовала себя великолепно.

Она берёт wlroots(ну labwc, который тоже на wlroots) и чувствует себя прекрасно дальше.

Разработчику приложений вообще не нужно заморачиваться под каким wm его программа будет работать.

Он берёт системный тулкит (Qt/Gtk/etc.) и не заморачивается.

Мне нужно XFree86 вспоминать чтоли? Тоже X11. Последний релиз в 2008 был, между прочем. Давай, проверь стабильность. Запусти на нём современный десктоп.

Что за нелепая подмена понятий? Запуск нового софта на платформе 20-летней давности гарантировать никак нельзя. Ты бы ещё пожаловался что современный софт на 80286 (16-битном проце) не работает и на этом основании ругал x86. Впрочем, нормальный современный WM скорее всего будет работать на XFree86 нормально.

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

Тебе нужно расширение Xrandr в твоем сетапе X-сервера его нет или версия его ниже чем надо (пример теоретический).

все X11 расширения проверяются на старте твоего приложения, аналогично и с версионностью… я уже готов тебя заменить на cloude) сорян, но ты не нужен…

Запуск нового софта на платформе 20-летней давности гарантировать никак нельзя.

X11 с тех пор поменялся? Нет. он вообще выпущен в 1987г. Претензии к композиторам Wayland? Классическое «это другое».

иксы ещё 30 лет назад довели то того состояния, когда в них есть всё нужное

Угу. Именно поэтому городили костыли мимо них, которые лет 10 героически вычищали?

А вот вайланд доделать до годного состояния не могут и не смогут никогда, ибо профнепригодны.

Где-бы ознакомиться со списком Ваших проектов соответствующего уровня. Ну, компетентность, все дела.

X11 by design.

Пустные фантазии не имеющие отношения к реальности.

Потому что упёрлись в его ограничения.

Ужос какой. Скоро четверть века сижу на иксах и оказывается всё это время меня что-то ужасно ограничивало.

Придумали wayland, другого не придумалось.

Не получилось, бывает.

Мне нужно XFree86 вспоминать чтоли? Тоже X11.

И в чём проблема? У меня с ним ни разу проблем не было.

Она берёт wlroots

На котором не работает ничего, что использует KDEшные расширения протокола. Пользователи ругаются и убегают. Конец.