Почему GPUI и egui загоняют сложные десктопные приложения в тупик
A Critique of GPUI
Автор, портировавший рендерер GPUI на wgpu и работающий над signal-фреймворком zgui, утверждает: модели состояния GPUI и egui не масштабируются. В GPUI изменение одного значения требует ручного notify и перерисовывает все view без кэша — на 3000 строк это 8,4 мс, а без кэша 92 мс. Попытка сделать обновления точными превращает простой render в ручную сборку signal-графа из тяжёлых сущностей, где пропущенная связь остаётся незамеченной.
Сохраните приятный API — получите обновления размером с view. Возьмите точность — потеряете приятный API.
- virtualritz
Главный аргумент, повторяемый в посте бесчисленное количество раз: «Это не масштабируется».
На что я отвечаю: «Кого это волнует, у подавляющего большинства приложений нет сложных интерфейсов».
А если есть, можно придумать обходной путь, как, например, сделали rerun для egui (описано в статье).
Показательный пример: мой самый большой «подсказанный» проект в свободное время — это гибридное приложение для 3D-моделирования, теперь уже 500 тыс. строк кода. Оно использует egui.
Я бы сказал, что по функциональности моделирования оно где-то между Grasshopper/Houdini, около 200 узлов из коробки + любое количество пользовательских.
Это даёт представление об интерфейсе: граф узлов, редактирование параметров, оверлеи виджетов, гизмо. У многих узлов есть кастомные виджеты, редакторы рампов или кривых и т.д.
Это совсем не простой интерфейс.
Но я ни секунды не тратил на беспокойство о производительности подхода egui. И хотя интерфейс отображается в моей статистике по кадрам, его вклад ничтожен.
- x-complexity
Это реклама zgui, замаскированная под критическую статью.
Из самой статьи:
> Раскрытие: я портировал текущий Linux-рендерер GPUI на wgpu2, я создал тестовый стенд, используемый ниже, и я работаю над zgui, сигнальным Rust-фреймворком, который появляется на графиках.
https://github.com/zortax/zgui
zgui только что выпустил версию 0.1.0 в прошлом месяце, с 3-месячной историей разработки. И это их единственная версия.
https://github.com/zed-industries/zed/tree/main/crates/gpui
https://crates.io/crates/gpui/versions
Последний релиз GPUI был 0.2.2 год назад.
Зрелость фреймворка — неизбежный фактор при выборе, куда портировать своё приложение.
Значит ли это, что можно выбирать только 10-летние фреймворки? Нет, но и гоняться за месячными проектами тоже не стоит.
Есть минимумы и максимумы, и минимум находится на уровне «определённо не проекты месячной давности с единственным публичным релизом».
- jharsman
Тема интересная, но сгенерированный ИИ текст очень трудно читать, и это заставляет меня сомневаться, действительно ли автор обдумывал проблему.
Если ты обдумывал, напиши сам.
- faangguyindia
Итак, какие самые продвинутые GUI-фреймворки когда-либо существовали и почему они превосходят GPUI или egui?
Какая компания в прошлом нуждалась в GUI больше, чем Microsoft? Может, у них есть ответ? Или у Apple?
Я не думаю, что приложения соцсетей достаточно нагружены GUI, чтобы разработать что-то продвинутое в этой области.
Сложность GUI и сложность приложения — две разные вещи.
Аргументы в посте звучат разумно, но вывод неверен.
- bluegatty
Выглядит забавно, но Rust меньше подходит для UX, чем другие языки — древовидные структуры данных, много уродливого состояния, событийно-ориентированность, сильная асинхронность, и, естественно, все json и прочее, что приходит на этом уровне, не имеет «очень хороших» библиотек.
Он совсем не использует преимущества Rust, и поэтому дополнительные издержки трудно оправдать.
Я думаю, есть несколько ключевых библиотек, которые хорошо работали бы с Rust (wgpu — отличная!), но сам язык в идеале не должен быть Rust.
Очевидно, это можно сделать, и я уверен, некоторым разработчикам это очень весело, но, по-моему, это попытка впихнуть круг в квадратное отверстие. (Прим. — забавно это говорить, потому что «впихнуть круг в квадратное отверстие» — это буквально как сказать «гулять?» собаке, то есть «подъём — есть проблема для решения!», но я думаю, именно это я и имею в виду: то, что виляет хвостом, не обязательно лучший вариант.)