LINUX.ORG.RU

Бывают ли человечьи Immediate Mode GUI?

 ,


0

2

Я тут столкнулся с понятием Immediate Mode GUI. Начинается там все со стандартного «MVC плёха» но дальше чувствуется запах серы :). Я в принципе положительно отношусь к выпиливанию стейтов, но делать это ценой смешивания кода со всем чем-то можно - как-то подозрительно. Как там анимацию приделывать - вообще непонятно.

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

★★★★★

Дак вся суть IMGUI в том, что библиотеки в целом нахрен и не нужны — почти всё делаешь руками. У меня J2ME-калькулятор по этой парадигме сделан, там голый, по сути, GameCanvas, на котором рисую, и события нативные, и это всё в моей лапше обрабатывается. Там и анимации есть; в одной из переменных задаётся текущий режим графики, отдельные режимы на вьюхи и отдельные на анимации, пока рисуются анимации — всё блочится, естественно (путём того, что при обработке событий эти режимы игнорятся тупо).

Зато всё чётенько и предсказуемо работает, как и нативные гуйцы на телефоне; мне блин, на десктопе этого дико не хватает, нажимаешь кнопку — и хрен пойми, куда это нажатие уйдёт: стопицот виджетов на экране, фокус может быть на любом, и в любой момент может вылезти какая-то бяка и перехватить на себя фокус. Хоть в CLI этого бардака нету, и то хлеб.

anonymous ()

Начинается там все со стандартного «MVC плёха»

с появлением идеологии реакта все эти замечательные MVC, а также их многочисленные архитектурные родственники типа MVVM, MVP и т.п. заслуживают только одно место, которого они достойны. на помойке.

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

с появлением идеологии реакта все эти замечательные MVC, а также их многочисленные архитектурные родственники типа MVVM, MVP и т.п. заслуживают только одно место, которого они достойны. на помойке.

Ничего, что реакт - это только буква V из всего названного?

devzero ()

Глупый вопрос, а в чём ключевое отличие?

Вот у меня есть свой GUI тулкит для игры. Я его написал по принципу «чтобы было удобно его писать». Прочитал и не понимаю, к чему его в итоге отнести?

Ещё немного погуглил. Я не понимаю смысла ежекадровой перестройки UI. Вот в чём польза превращения кода UI в лапшу?

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

Ещё немного погуглил. Я не понимаю смысла ежекадровой перестройки UI.

Отрисовка всё равно ежекадровая. Если перестройка занимает не больше (или не намного больше) циклов, чем хранение состояния, то проще перестраивать.

Вот в чём польза превращения кода UI в лапшу

В CLI программах вы тоже все вызовы scanf/printf в отдельный модуль выносите, чтобы не «превращать код CLI в лапшу»?

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

Не понимаю. Что не хватает в https://cloud.githubusercontent.com/assets/8225057/8307152/3eb04a4c-197a-11e5... , например? Или в https://cloud.githubusercontent.com/assets/8225057/13198792/92808c5c-d812-11e... .

А мне хотелось бы подобие Material Design.

Можно пример? https://material.io/design/material-studies/shrine.html как-то не впечатляет.

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

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

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

CLI это не GUI. Хочешь сравнить консольку с графикой, давай проводить сравнения с TUI.

Если перестройка занимает не больше (или не намного больше) циклов, чем хранение состояния, то проще перестраивать.

Я не про ресурсы. Удобно представлять что у твоего виджета есть определенный lifetime, их можно засунуть друг в друга, есть родители, есть дети. Я не говорю уже про то, что это привычно, это просто логично — держать объекты со своими стейтами.

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

Более того, а как imgui как концепт накладывается на рендеринг регионами(или как вы хотите ещё его назвать называйте)? Это вообще важно для банальной энергоэффективности. Ибо идея в том, что нет смысла перерисовывать то, стейт чего не поменялся.

Я в свой уже упомнятый GUI тулкит планирую завезти такой режим отрисовки. Например чтобы его завести в embedded Linux, где доступен какой-нибудь экран.

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

CLI это не GUI. Хочешь сравнить консольку с графикой, давай проводить сравнения с TUI.

А в чём разница? Почему в CLI считается нормальным перемешивать логику и ввод/вывод, а в GUI внезапно надо писать словно на Haskell полностью отделяя логику и интерфейс?

Удобно представлять что у твоего виджета есть определенный lifetime, их можно засунуть друг в друга, есть родители, есть дети.

Вот в этом и разница. Ведь ты не представляешь, что у строки «Login:» при запуске есть определённый Lifetime. Что можно считать её родителем строки «Password:» и т.д. И вообще писать в стиле https://gist.github.com/madsaune/7749294

В этом и есть принципиальное различие ImGUI и OOP GUI. Для ImGUI виджеты не объекты. Это просто вывод данных или ввод данных. Всё.

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

В случае Dear ImGUI формируется текстура GL (или аналогичной библиотеки), а уже он перерисовывает.

Цитирую: A common misunderstanding is to mistake immediate mode gui for immediate mode rendering, which usually implies hammering your driver/GPU with a bunch of inefficient draw calls and state changes as the gui functions are called. This is NOT what Dear ImGui does. Dear ImGui outputs vertex buffers and a small list of draw calls batches. It never touches your GPU directly. The draw call batches are decently optimal and you can render them later, in your app or even remotely.

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

Вот у меня бэкграунд и 10 не пересекающихся прямоугольников. 9 ничего не делают, 1 запрашивает перерисовку для анимации.

Как это накладывается на imgui, если ты не знаешь предыдущее состояние и не уверен, что 9 прямоугольников и бэкграунд уже были отрисованы и есть в FBO или даже на экране уже?

Я вот глянул в реализацию и не нашёл ничего подобного. Ну VBO. И что? Цитата вообще не о том, о чём я спрашиваю.

Про CLI. Я не могу их сравнивать, потому что консоль исторически это последовательное устройство, будь то физический телетайп или виртуальный. И в большинстве программы пишутся, предполагая что нет возможности и необходимости возвращаться на предыдущее состояние. Вход в начале main(), выход там же, в конце. Где-то между ними получал ввод, что-то обрабатывал и куда-то сохранял. Никаких event-loop-ов, никаких exit() посередине исполнения.

В GUI/TUI так не бывает. Юзер имеет свободу производить действия в любом порядке, гоняя программу из одного состояния в другое и обратно, пока наконец юзер не нажмёт кнопку выйти.

При чём тут imgui? А ни при чём. Это я про фундаментальную разницу CLI и GUI, как я её понял для себя.

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

с появлением идеологии реакта все эти замечательные MVC, а также их многочисленные архитектурные родственники типа MVVM, MVP и т.п. заслуживают только одно место, которого они достойны. на помойке.

React? React + Redux это еще одно MVC, где React - View , Store - Model, Redux - Controller, Action - Interactors (из Taligent MVP).

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

1 запрашивает перерисовку для анимации.

В случае imgui это утверждение не имеет смысла. Верно так: программа отрисовывает фон и 10 прямоугольников на нём, один из которых в каждом кадре разный. Если отрисовка идёт в видеодрайвер, то он сам определит, какие области обновились. Ну или можно вручную двойную буферизацию реализовать.

И в большинстве программы пишутся, предполагая что нет возможности и необходимости возвращаться на предыдущее состояние. Вход в начале main(), выход там же, в конце. Где-то между ними получал ввод, что-то обрабатывал и куда-то сохранял. Никаких event-loop-ов, никаких exit() посередине исполнения.

Все диалоговые программы имеют и главный цикл и exit() или return на команду выхода. Примеры: ed, mail, любой интерпретатор, ...

Юзер имеет свободу производить действия в любом порядке, гоняя программу из одного состояния в другое и обратно, пока наконец юзер не нажмёт кнопку выйти.

В CLI также. В том же консольном mail я могу делать любое действие над письмами пока не введу команду q.

Вся разница только в том, что в CLI все команды приходят через scanf, а в GUI через нажатия мышки/клавиатуры.

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

зачем тащить за собой весь этот старый, ненужный хлам? не понимаю.

Действительно. Зачем писать loosely coupled code, если можно писать spaghetti code, понятный только тебе, и быть незаменимым сотрудником, которого хрен уволишь. Не понимаю.

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

Спасибо. Попробую еще раз посмотреть внимательнее.

Насчет анимации - в примере не совсем то что я спрашивал. Там скорее видосик внутри канваса. А мне надо типа выезжающих боковых менюшек, всякая красивая кинетика на прокрутке и т.п.

https://github.com/littlevgl/lv_examples/issues/26#issuecomment-473279547 - вот тут есть скриншоты того, что хотелось бы навалять.

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

«Ребята, хватит заниматься ерундой. Персонального компьютера не может быть. Могут быть персональный автомобиль, персональная пенсия, персональная дача. Вы вообще знаете что такое ЭВМ? ЭВМ это 100 квадратных метров площади, 25 человек обслуживающего персонала и 30 литров спирта ежемесячно!»

«640k ought to be enough for anybody»

«32-bit address space is quite enough for PC»

«Сейчас CPU/GPU хватает с большим запасом на UI» <- вы находитесь здесь

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

Тем не менее его продолжают реализовывать. Если есть рядом Android устройство, там можно включить режим, где подсвечиваются обновленные прямоугольники. Там их два — один про окна(кстати тоже полезно, можно посмотреть как работает композитор), второй про частичную перерисовку.

monk, я быть может ошибаюсь, но драйвер GPU и сам GPU хоть и могут так делать, но не обязаны.

Да. С интерпретаторами я немного погорячился. TUI их вроде не назовёшь.

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

Там скорее видосик внутри канваса. А мне надо типа выезжающих боковых менюшек, всякая красивая кинетика на прокрутке и т.п.

Ясно. Такое потенциально сделать можно (технически оно не отличается от реализации обычной прокрутки). Но практически никто заморачиваться не будет, так как на анимацию нужно кучу кода, а ImGUI библиотеки позиционируются как легковесные. Если легковесность не требуется, можно Qt статически прилинковать, там и анимация и всё остальное.

https://github.com/littlevgl/lv_examples/issues/26#issuecomment-473279547 - вот тут есть скриншоты того, что хотелось бы навалять.

Либо не та ссылка, либо не понял. По ссылке картинки слайдера, галочки, ввода числа кнопками и радиокнопок. Всё это в ImGUI есть и выглядит не хуже.

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

но драйвер GPU и сам GPU хоть и могут так делать, но не обязаны

Я же написал: можно вручную двойную буферизацию делать. Просто для ImGUI это уровень ниже: OpenGL, SDL, ...

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

И... тем не менее ты всё равно не можешь сэкономить на gl вызовах.

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

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

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

GUI в принципе не может быть «чем-то серьёзным». Также как не может быть чем-то серьёзным файловый ввод/вывод.

Насчёт «действительно оптимальной отрисовки» вспоминается, что у React'а пересчёт изменений происходит дольше, чем собственно графический вывод. И старые ОС, где планировщик процессов всегда выбирал оптимальный план выполнения. И процесс выбора при большом количестве процессов происходил дольше, чем само выполнение. Поэтому сейчас в линуксе O(1) планировщик, а оптимизация отрисовки возложена на видеокарту.

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

Объектная модель - да. Что значит «прибитыми». Контрол там — что угодно с методом render. И при отрисовке строится DOM и разность с предыдущим состоянием. Для большого количества простых объектов тормозит.

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

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

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

Я не против, хочешь - делай. Просто отметил что не стоит в это упираться как в уберфичу, от которой все зависит и без которой ничего не взлетит.

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

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

Например, в вебне есть подходы, когда код вкрячивается в темплейты отображения. Но это делается не совсем от балды. И мне был не совсем понятен переход в imgui от базовых принципов к имплементации:

[ full frame render, no state ] => [ код рисовалки ]

Либо не та ссылка, либо не понял. По ссылке картинки слайдера, галочки, ввода числа кнопками и радиокнопок. Всё это в ImGUI есть и выглядит не хуже.

Представь что у тебя дисплей 200*200, и это скриншоты. Есть список настроек, когда в какую-то тыкаешь, сбоку выезжает один из вариантов. Как на мобилке.

Херить анимацию крайне не желательно.

Vit ★★★★★ ()