[解決済み] リテインドモードGUIと比較して、イミディエイトモードGUIを使用した場合のパフォーマンスにはどのような影響がありますか？

質問事項

現在、Windowsの標準的なデスクトップアプリケーション（標準的とは、ボタン、テキスト、スライダーなどの派手なものがないという意味です）を作っているのですが、いくつかのGUIフレームワークを調べて、そのすべてに反感を持ったため、自分でGUIフレームワークを書くことにしました。趣味のプロジェクトなので、実験もいとわず、GUIをretain-modeではなくimmediate-modeにして、コードを単純化する方法がとても気に入ったので、決めました。しかし、ここで疑問があります。

典型的なデスクトップ・アプリケーションに使用する場合、リテインド・モードGUIと比較して、イミディエイト・モードGUIを使用することのパフォーマンスへの影響はどの程度ですか？

IMGUIはフレームごとに再描画しなければならないので、パフォーマンスが悪くなるといつも聞きます（何らかの方法でキャッシュしている場合でも、フレームごとにロジックを実行する必要があります）。しかし、ここではどの程度多く話しているのでしょうか？私は2倍のCPU時間を費やしているのでしょうか？もっと？もし、私が20のIMGUIプログラムを走らせたと仮定すると、それはCPUを最大にするでしょうか（私がすでにそれを最適化したと仮定して）？私は、フレームごとに再描画する必要がない非ゲーム環境において、そのトレードオフがまだ実行可能であるかどうか、大まかなところを知りたいだけです。

もうひとつ、レイテンシーに関して、理解できないことがあります。それは の章では、IMGUIについて説明しています。 の中に ワークインプログレスブック による ヨハネス・ノルネビー は、次のように説明されています。

フレームシャーリング

IMGUIのリアルタイム性の文脈で注意すべき点の1つは、次のとおりです。 アプリケーション（常に新しいフレームを1秒間に何度もレンダリングする）において ユーザーとのインタラクションは、常に何かに対する反応であるということです。 前のフレームに描画された これは、ユーザーインターフェイスが ウィジェットがあることを認識させるために、少なくとも一度は描画されます。 との対話が必要です。ほとんどの場合、このことは フレームレートが十分高ければ問題ないのですが、注意すべき点です。 を意識しています。

リテインドモードのGUIではどう違うのでしょうか？retained-mode GUIより1フレーム多くインプットラグがあるということでしょうか？

解決方法は？

この質問にはまだ関心があるようなので（閲覧数から判断して）、更新を投稿した方がいいと思いました。

修士論文でイミディエイトモードGUIを実装することになり、パフォーマンスについていくつかの数値を確認しました。その要点は

大丈夫です。システム的な特性ではなく、実装の品質が支配的です。

他の多くの既存のリテインドモードGUIと比較すると、私のイミディエイトモード実装は一般的にかなり高速に動作しています。パラダイム間の理論的な性能差は、ほとんどのGUIが恐ろしく最適化されていないという事実によって打ち消されています。全体として、imguiは、高速に応答し、バッテリーを消耗しないGUIを作成するための完全に実行可能なアプローチです。

UI要素を50%程度にしてSpotifyクローンを作ってみましたが、1フレームのレンダリングがマイクロ秒台でした。実際、このアプリケーションでは、1フレームに使用する時間は常に400μs未満でした。60HzのモニターでV-Syncを有効にした場合、これは約3％のCPU負荷に相当します。 シングルコアで (400μs/16ms)となります。 単純な実装の場合 . さらに、この400μsの大部分は、UI要素が増えても負荷が増加しない定数要因によるものでした（たとえば、入力の受信や、UIの複雑さに比例しないGPUステートのセットアップなど）。

完璧主義者の私は、何もしないGUIがサイクルを消費していることをまだ嫌っていましたが、その反面、大きなメリットもありました。 GUIが大きく操作されたり、ウィンドウがサイズ変更されたりしても、400μsを記録していました! これは、既存の多くのリテインドモードGUIを吹き飛ばすものです。Spotify、Windows Explorer、Visual Studio、その他のデスクトップアプリケーションのサイズを変更してみて、その反応を見れば、私の言っていることが理解できるはずです。私のPCでは、リサイズするとSpotifyは2fps程度まで落ちると思います。