Я давно откладывал эту тему, но вот вышла эта новость, и, видимо, пора:

https://www.opennet.ru/opennews/art.shtml?num=56587

"Отмечается, что для полноценной работы приложений на базе SDL в Wayland требуется наличие библиотеки #libdecor для декорирования окон на стороне клиента."

libdecor - это леденящий душу пиздец.

Очень хорошо со стеком #glib /gtk я познакомился под НГ, когда собирал себе браузер Epiphany, на основе WebKitGTK(*).

* Он написан на диалекте С от GNU. Это очень странная объектная система, которая позволяет конструировать классы на лету, и несщадно тормозит, потому что минимум 2 уровня косвенности.

* Он жрет много памяти. Потому что любой объект в куче, там нет оптимизации любой нормальной VM, позволяющей создавать большинство объектов на стеке.

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

* Он косой и кривой - я заметил, что браузер всегда мерцает(1 кадр - белый фон, второй - реальная картинка(видос записывать лень)). Бугага, зато девелоперы пишут победные статьи - https://blogs.igalia.com/carlosgc/2017/02/10/accelerated-compositing-in-webkitgtk-2-14-4/. Ремарка - плохие девелоперы у Igalia, не у WebKit.

В процессе исследования это проблемы я пришел к следующему интересному выводу: динамической линковкой в мире OSS решают две проблемы:

* Кто-то с кем-то не договорился. #fontconfig
* Круговые зависимости.

Сегодня про первую проблему :) #GNOME #SSD

Вот такой феерический тред - https://gitlab.gnome.org/GNOME/mutter/-/issues/217. Обязательно его прочитайте! Краткое содержание - все упрашивают разработчиков Gnome добавить поддержку server side decorations, а они отказываются, мотивируя тем:

* Что могут(Wayland не требует поддержки SSD).

* Что их собственный композитор не зависит и не должен зависеть от GTK. Дебилы, у меня нет других слов.

И, тем самым, не-GTK приложения должны в себя влинковывать GTK, чтобы не выглядеть в Gnome чужеродно. Чувствуете логику, да? То есть, не 1 гномовский композитор должен зависеть от их платформенной библиотеки, а каждое приложение на QT должно зависеть от чужой платформенной библиотеки.

Короче, TL;DR - они не договорились, и появилась библиотека libdecor, которая должна в runtime загрузить в себя плагин, который загрузит GTK в QT приложение, запустит в отдельном event loop GTK, и будет отрисовывать клиенсткие декорации.

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

И вот, теперь безвинные приложения на SDL будут загружать это УГ, и рисовать им декорации.

Я после этого треда очень сильно поменял свое отношение к этим упырям из Gnome, они реально негодяи. Считают, что GTK - это платформенный тулкит, и все должны под него подстраиваться. С его-то проблемами.

* Почему WebKIT? Мне показалось, что его проще всего собрать, потому что меньше мудохаться с вендорингом. Я ошибался, но это уже другая история.

https://www.phoronix.com/scan.php?page=article&item=apple-m1-compilers&num=1

После запуска Linux на M1 стало возможным проверить codegen от gcc для Apple M1. Под darwin оно уже давно сломано от слова совсем.

Я, если честно, сильно удивлен результату, gcc, в среднем, генерит все еще более лучший код для aarch64, несмотря на то, что clang - родной компилятор для M1.

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

———
Много ссылок про Wayland, без особого порядка и смысла, просто накопилось, хочу сбросить dump, чтобы перестать про них помнить.

https://www.reddit.com/r/linux/comments/u3m7s0/chromium_is_developing_support_for_using_qt_on/i4rg0jr/

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

Например, https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/132. Ну простая же задача, сделать поддержку картинки-в-картинке? Это такое оверлейное окно поверх всего остального.

"There's a merge request for adding PIP support to wayland-protocols, but as a surprise to absolutely nobody, it's stalled because some upstream developer thinks it shouldn't be done like specified, because it goes against the wayland philosophy. So, that's going to take optimistically 3 more years, for a really minor feature, to be officially supported with Wayland."

Ну так эти капризные мудаки, которым непонятно кто дал этот жалкий кусочек власти, начинают обсуждать космические корабли, бороздящие просторы Большого театра - "а можно input туда, или нет", "а может, разрешить туда только видеопоток", etc.

Кстати, fun fact - 50gb chrome source vs kernel 1gb source. Никогда не задумывались, насколько chrome огромен?

https://gitlab.freedesktop.org/mesa/mesa/-/issues/6249 - интересное обсуждение в Mesa отличие построенного пайплайна в RADV(4 буфера в swapchain vs. 2 буфера в #AMDVLK).

https://www.opennet.ru/opennews/art.shtml?num=57038 - SDL отменяет "wayland по умолчанию". Одна из причин - #libdecor не всегда корректно подхватывает плагины для отрисовки декораций. Про леденящий пиздец под названием libdecor я уже однажды рассказывал, поэтому, думаю, мое злорадство тут вполне понятно и уместно. У меня, конечно, в силу статической линковки все всегда работает как надо.

Про libdecor еще добавлю:

* Как бы нормальный разработчик сделал fallback в случае отсутствия необходимого плагина? Ну, понятно, был бы или плагин, который всегда устанавливается в систему, или плагин, который принудительно линкуется в основное приложение.

Чувак сделал и то, и то - ему, наверное, за строки кода деньги платят.

https://gitlab.gnome.org/jadahl/libdecor/-/blob/master/src/libdecor-fallback.c - линкуется принудительно
https://gitlab.gnome.org/jadahl/libdecor/-/blob/master/src/plugins/dummy/libdecor-dummy.c - ставится по умолчанию всегда

Но и это еще не все! В поставку входит еще 1 плагин, который тоже ставится всегда, и делает что-то полезное!

https://gitlab.gnome.org/jadahl/libdecor/-/blob/master/src/plugins/cairo/libdecor-cairo.c

То есть, вместо того, чтобы просто по умолчанию всегда линковать эту реализацию с cairo, чувак 3 раза сделал одно и то же. Пиздец.

Ну и могу рассказать, как я элегантно из всего этого соорудил библиотеку с вкомпиленным внутрь плагином:

* В первый раз собираем libdecor, оставляем от нее только плагин, и в нем переименовываем и делаем global символ, который libdecor будет звать в виде fallback https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/decor/cairo/mix.sh#L16 , https://gitlab.gnome.org/jadahl/libdecor/-/blob/master/src/libdecor.c#L1657

* Во второй раз собираем libdecor, но обнуляем в ней символ libdecor_fallback_plugin_new, чтобы он взялся из плагина от первой сборки. https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/decor/mix.sh#L9