LINUX.ORG.RU

Нужны советы по созданию композитора Wayland на языке Rust

 , , smithay,


0

2

Есть у меня странное хобби - упрощать оконные менеджеры до минимума, урезая все ненужные мне фичи.

Например, я не пользуюсь тайлингом. Даже в Sway настроил так, чтобы вообще не было тайлинга. Однако, из-за того что Sway тайловый, всё таки баги есть: иногда окна под активным оказываются в фокусе клавиатуры, даже если курсор мыши над активным окном. Кроме того, в Sway глючат некоторые новые игры, такие как Atomic Heart и Horizon Forbidden West. Когда просто ходишь, то всё нормально, а когда начинаешь водить мышкой - экран дёргается. А эти игры на разных движках. Странно и то, что в игре Baldurs Gate 3 такого глюка нет даже в Sway. Кроме того, этого глюка нет, если поменять композитор на растовый Anvil.

На Расте есть библиотека Smithay, на которой активно разрабатывают новый оконный менеджер для Pop-Os (Cosmic). В принципе, годная вещь. И в ней нет этих глюков с играми. Но есть другие глюки. Пока что читаю исходники, разбираюсь что и как…

Тут в новостях периодически пишут что Wayland якобы «хуже Х11», но ведь очевидно что игры в Wayland дают лучший FPS. Как можно их сравнивать вообще? Есть какие-то идеи, как настроить тестовую конфигурацию для того чтобы сравнивать производительность? И вообще, мне интересно, какие есть идеи добиться максимального фреймрейта в полноэкранной игре? Ну или хотя бы ссылочки на ликбез по этой теме.

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

★★

Последнее исправление: dataman (всего исправлений: 1)

Нужны советы по созданию композитора Wayland на языке Rust

  1. Как можно больше библиотек из crates.io. Чем больше, тем лучше. Несколько гигабайтов библиотек сделают WM только лучше.

  2. Биндинги к Haskell, и чтобы обязательно использовался Stack. К биндингам тоже нужны гигабайты зависимостей.

  3. Обязательно упаковать во Flatpak, иначе не считается.

RectalReactor
()
Ответ на: комментарий от Vilicus

Ну такой себе совет. Я запарился с С++. Все эти попытки обойти криворукость std::string. И потом, в Расте есть менеджер пакетов Cargo - не надо копаться в библиотеках и их версиях. Я пока только начал изучать, но уже столько удобств!

svyatozar ★★
() автор топика
Ответ на: комментарий от RectalReactor

Не, ну лично я за статическую линковку. Уже задолбали эти сегфолты из-за несовместимости версий динамически связанных библиотек. И так уже это привело к тому, что приходится устанавливать гигабайтные пакеты AppImage, Docker, Snap с его постоянно запущенным сервисом…

svyatozar ★★
() автор топика
Ответ на: комментарий от svyatozar

Два плюса выкинь и можешь начать писать

buddhist ★★★★★
()
Ответ на: комментарий от X512

Благодарю за ссылочки. Буду изучать. Вижу, есть wayland-egl, а есть смысл использовать Vulkan? Не будет egl тормозить игры для вулкана?

svyatozar ★★
() автор топика

Есть у меня странное хобби

Теги придумывать? :)

rust wayland smithay compositor

dataman ★★★★★
()
Ответ на: комментарий от svyatozar

Для того чтобы заработало аппаратное ускорение композитинга, надо рисовать принятые от клиента буферы dma-buf через EGL/Vulkan. Выбор EGL/Vulkan большого значения не имеет, но с Vulkan будет больше писанины. Можно взять какую нибудь готовую библиотеку для аппаратного рисования вроде Skia которая сама всё сделает, вызывая внутри EGL/Vulkan.

X512 ★★★★★
()
Ответ на: комментарий от X512

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

svyatozar ★★
() автор топика
Ответ на: комментарий от Parthen

У char* есть вот какая проблема. Что если у тебя есть неизменяемый текст для парсинга, и ты хочешь ничего не копируя разбить его на «токены». По идее, нужна такая структура, которая хранит адрес начала и длину строки. char* же рассчитывает на специальный стоп-символ в самой строке. Можно, конечно, заморочится и самому запилить такую структуру, но ведь и все базовые функции обработки строк тоже надо под неё переделывать. А в Расте это всё изначально встроено!

svyatozar ★★
() автор топика
Последнее исправление: svyatozar (всего исправлений: 1)
Ответ на: комментарий от svyatozar

Можно, конечно, заморочится и самому запилить такую структуру

Ничего не надо пилить, std::string_view чудненько работает с char*.

pr849
()
Ответ на: комментарий от pr849

Ага, а ещё он прекрасен тем, что для сборки постоянно надо вручную искать все зависимости, нужные версии библиотек, а некоторые уже не совместимы с данной версией дистрибутива операционной системы, либо не могут быть одновременно установлены с аналогами на данном дистрибутиве Линукс. Или одна программа требует библиотеку N, собранную с фичей X, а другая требует библиотеку N, собранную с фичей Y, причём фичи X и Y взаимоисключающие, подобно драйверам Невидии и АМД. Обрыдло!

svyatozar ★★
() автор топика
Последнее исправление: svyatozar (всего исправлений: 3)
Ответ на: комментарий от svyatozar

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

MOPKOBKA ★★★★
()
Ответ на: комментарий от MOPKOBKA

Есть ещё NixOS, где каждая версия каждой установленной библиотеки живёт в своём отдельном дереве глубоко в директориях. Каждая программа привязана к определённой версии каждой используемой юиблиотеки. Это, конечно, очень круто, но что если хочется просто собрать и запустить программу из исходников? Это такой жуткий гемор! Даже для задротов это невероятно замороченная шиза. То есть все недостатки статической линковки (всё равно все эти разные версии занимают место на диске) ПЛЮС все заморочки с написанием/поддержкой скриптов на самодельном языке. Моё почтение таким задротам, потому что поддержка такой системы в разы сложнее Gentoo со всеми её лабиринтами зависимостей от библиотек, собранных с различными USE-параметрами!

svyatozar ★★
() автор топика
Последнее исправление: svyatozar (всего исправлений: 1)
Ответ на: комментарий от svyatozar

В C++ есть string_view, в C даже printf умеет в строки без завершающего нуля.

Проблем больше в ОС, они часто не умеют в такие строки, придется их постоянно дополнять нулем. Даже если в std:: добавят функцию на открытие файла без нуля в конце, то все равно оно будет внутри ее конвертировать.

MOPKOBKA ★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 1)
Ответ на: комментарий от svyatozar

Это все продолжение идеи с флатпаками и докерами.

MOPKOBKA ★★★★
()
Ответ на: комментарий от MOPKOBKA

я как-то ковырял JerryScript - JS интерпретатор для контроллеров, так там они заморочились и реализовали вручную свои строки. Конечно, это круто, но я потом вспомнил что для Си тоже пытались делать что-то вроде STL - была такая библиотека Apache Portable Runtime. Но, к сожалению, её функционал был минимален, в ней было только то, что необходимо для веб сервера Апач… Вобщем, загнулся проект. Болото. И «всем пофиг». Такая вот грустная ситуация с Си, как это выглядит с моей колокольни.

svyatozar ★★
() автор топика
Ответ на: комментарий от svyatozar

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

MOPKOBKA ★★★★
()
Ответ на: комментарий от svyatozar

для Си тоже пытались делать что-то вроде STL

И не перестают пытаться. :)
Пожалуй, одна из самых активных попыток: https://github.com/stclib/STC.

STC is a modern, typesafe, fast and compact container and algorithms library for C99. The API naming is similar to C++ STL, but it takes inspiration from Rust and Python as well. The library handles everything from trivial to highly complex data using templates.

Containers

  • arc - (atomic) reference counted smart pointer
  • box - unique smart pointer
  • cbits - dynamic bitset
  • list - forward linked list
  • stack - stack type
  • vec - vector type
  • deq - double ended queue - deque
  • queue - queue type
  • pque - priority queue
  • hmap - hashmap (unordered)
  • hset - hashset (unordered)
  • smap - sorted binary tree map
  • sset - sorted binary tree set
  • cstr - string type (short string optimized)
  • csview - string view (non-null terminated)
  • czview - null-terminated string view
  • cspan - single and multidimensional span

Algorithms

  • Ranged for-loops - c_foreach, c_forpair, c_forlist
  • Range algorithms - c_forrange, crange, c_filter
  • Generic algorithms - c_init, c_find_if, c_erase_if, quicksort, lower_bound, …
  • Coroutines - ergonomic portable coroutines
  • Regular expressions - Rob Pike’s Plan 9 regexp modernized!
  • Random numbers - a very fast PRNG based on SFC64
  • Command line argument parser - similar to getopt()
dataman ★★★★★
()

честно просто пиши, любой опыт это опыт(посмотри что уже написано на раст в частности библиотеки фраемворки или что там используеться)

SPRATAY ★★
()
  1. Здесь не любят Вэйланд.
  2. Здесь не любят Раст.

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

Virtuos86 ★★★★★
()
Ответ на: комментарий от Virtuos86

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

svyatozar ★★
() автор топика

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

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

Что касается wayland vs x11, то всё довольно просто: есть люди, которые хотят прогресс и максимально использовать свои gpu; есть люди, которым наоборот, не надо ничего, лишь бы всё работало ещё 50 лет на их пентиуме 20-летней давности, и не деградировало ни на миллиметр. И вот первым кажется что они выжали ещё пару FPS в игре, потому что из оконной системы удалили легаси; вторым кажется что дурью маются от нечего делать и всё сломали без толку. На деле вейланд нужен был чтобы приложения изолировать друг от друга, запрашивать разрешение у пользователя на всякие расшаривания экранов, перестать поддерживать огромную неактуальную кодовую базу, так как действующих разрабов очень мало. То есть здесь нет вообще ничего о FPS в играх. Разве что процессы оконного менеджера и композитора соединили в один, и там вроде бы как стало чуть более оптимально взамен на более строгие требования к композитору, его уже просто так не перезапустить не убивая сессию.

Если хочется поиграть с композитором, то бери максимально готовую основу: wlroots или этот же smithay. Иначе забодаешься и ничего не сделаешь в итоге. Написать в одно лицо композитор с нуля долго и сложно. А ещё лучше модифицируй тот что тебе больше всего нравится.

neumond
()
Ответ на: комментарий от neumond

В эпоху интернета очень важно чтобы любая программа не могла быть кейлоггером или «подглядывать» за другими окнами.

Насчёт поддержки нестандартных игр: в настройках оконного менеджере Sway можно указывать настройки для каждого отдельного приложения. Вообще, в идеале надо предоставить пользователю меню как это было в Винде для поддержки старых программ. Типа «скажи мне что не так и я попробую это исправть». Думаю, такой подход лучше чем ничего. Ну и эксклюзивный доступ к экрану нужен для игры, ведь если она запущена на весь экран, то другие программы всё равно не видно.

Линукс удобен ещё и тем, что есть несколько логин-терминалов и можно запустить параллельно разные оконные интерфейсы - будь то X11 или Wayland. Если игра не работает в одном - запускаю параллельно другой и в нём игру. Поэтому, если какая-то игра и не запустится в моём композиторе, то это не так критично.

Насчёт готовой основы: определённо буду использовать Smithay. Wlroots гораздо более развит, но в Расте совсем другой менталитет, ориентированный на многопоточность. Если переменной нет нужды меняться, то она остаётся константой. Изменяемость переменной - большая роскошь в многопоточной среде и, исходя из этого, сильно меняется вообще всё: по-другому структурируются данные, функции и нельзя просто взять и переписать Wlroots на Rust. Определённо, подход Smithay гораздо более перспективный. Тем более, что он сейчас активно развивается. Cosmic, для которого пишется Smithay вполне уже юзабельный.

svyatozar ★★
() автор топика
Последнее исправление: svyatozar (всего исправлений: 2)
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.