Производительность графического интерфейса непосредственного режима

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

Каковы последствия для производительности при использовании графического интерфейса непосредственного режима по сравнению с графическим интерфейсом с сохранением режима при использовании его для обычного настольного приложения?

Я всегда здесь, что imGUI работает хуже, так как он должен перерисовывать каждый кадр (или, если он каким-либо образом обнуляется, он все равно должен выполнять логику каждый кадр). Но сколько еще мы здесь говорим? Горю ли я вдвое больше времени процессора? Больше? Если бы я гипотетически запустил 20 программ imGUI, будет ли он максимально использовать процессор? (предполагая, что я уже оптимизировал его), я просто хочу знать приблизительный уровень, и если компромиссы все еще жизнеспособны в неигровой среде, где нет необходимости перерисовывать каждый кадр.

Есть также еще один вывод, касающийся латентности, который я не понимаю. На этом сайте это объясняется так:

Резка рамы

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

Чем это отличается в графическом интерфейсе с сохранением режима? Означает ли это, что у меня есть еще одна задержка ввода по сравнению с GUI с сохраненным режимом?

0 ответов

Поскольку, кажется, есть некоторый интерес к этому вопросу (судя по мнениям), я подумал, что могу также опубликовать обновление:

Я закончил тем, что реализовал графический интерфейс немедленного режима в качестве своей магистерской диссертации, и у меня есть некоторые цифры по производительности. Суть такова:

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

Я создал клон Spotify примерно с 50% UI-элементов, а рендеринг одного кадра находился в диапазоне микросекунд. Приложение постоянно ударяет <400 мкс для одного кадра. При включенной V-Sync и мониторе с частотой 60 Гц это составляет примерно 3% (400 мкс на 16 мс) загрузки ЦП на одном ядре. Более того: значительная часть этих 400us были постоянными факторами, которые не могли масштабироваться с большим количеством элементов пользовательского интерфейса (например, ввод или настройка графического процессора).

Перфекционисту во мне по-прежнему не нравится тот факт, что графический интерфейс, который ничего не делает, потребляет циклы, но преимущества были огромными: когда графический интерфейс интенсивно взаимодействовал или когда изменялся размер окна, он все еще достигал 400 мкс! Это выбивает из воды графический интерфейс пользователя с сохраненным режимом. Попробуйте изменить размер Spotify, Windows Explorer, Visual Studio или чего-нибудь еще и посмотрите, как они отреагируют, чтобы понять, что я имею в виду. Я предполагаю, что Spotify понижает скорость до 2 кадров в секунду на моем ПК при изменении размера.

Изменение пользовательского интерфейса в основном бесплатное. Если вы отобразили 100 кнопок во фрейме, а затем заменили их все на текстовые поля в следующем, по-прежнему нет разницы в производительности. Опять же, графические интерфейсы с сохраненным режимом обычно не справляются с этим сценарием.

Еще 3 мысли:

  1. Большая часть времени уходит на рендеринг текста, остальное практически неактуально. Если вы хотите сильно оптимизировать, это будет сложной проблемой. Но даже с небольшой оптимизацией все будет неплохо.
  2. Я сомневаюсь, что огромная разница в производительности объясняется только или даже большей частью разницей между сохраненным и немедленным режимами. Spotify, например, использует веб-стек для пользовательского интерфейса, что должно быть медленным. Я полагаю, что WPF, Win32 и им подобные работают медленно, потому что им это может сойти с рук, или потому, что они были оптимизированы для совершенно других ПК, чем мы сейчас. Они также делают больше, но не настолько, чтобы оправдать разницу.
  3. Я уверен, что вы могли бы создать графический интерфейс в сохраненном режиме, который намного быстрее, чем мой графический интерфейс в непосредственном режиме. В целом для этого мало стимулов, что немного печально. Мне нравятся эффективные вещи.

Ключевой вывод для меня: все в порядке, вы можете сделать это быстро.

Другие вопросы по тегам