3 ms·

You making a blanket statement based on what Unity (one implementation with its own particular design/features/requirement) did. I've rarely heard of people hav

by ocornut 10y ago

You making a blanket statement based on what Unity (one implementation with its own particular design/features/requirement) did. I've rarely heard of people having unsolvable performance issues with dear imgui. The layout features and other features are carefully designed with performances in mind.

TillE 10y ago
It's an inevitable drawback of the entire concept of an immediate-mode GUI that gets recreated from scratch on every frame. There are major types of optimization which are simply impossible. The vast majority of games use simple GUIs where it won't matter. But if you have a complex or large GUI, you will be eating up significantly more CPU cycles.
- ocornut 10y ago
  Displaying a few hundreds widgets has absolutely negligible cost if the code is written properly. For large lists they can always be clipped and not submitted at all. With an immediate-mode GUI you can actually handle navigation of a list of one million items whereas more RMGUI would struggle because of all the intermediate data involved. Also, the optimization bottleneck nowadays is mostly programmer/brain time, so having a ten-fold productivity improvements means you can actually create more/better tooling and that has very direct consequence on your software performance. The reality with toolkits like QT is that people write very little amount of tooling with it, because it is so tedious. The cost of that are lost opportunity in improving a game engine and its performances.
- flohofwoe 10y ago
  In my experience the main problem with performance in UI system is not layout, but draw calls and render state changes. There are some braindead UI solutions that build a hierarchical scene graph for rendering, with each node in the graph costing one draw call. Once you have such a system it doesn't matter whether the higher level parts follow the immediate-mode or non-immediate-mode philosophy, or if the scene graph itself is rebuilt each frame or not, just the render state changes and draw-call overhead will kill performance as soon as you have a few hundred UI elements on screen. Dear Imgui builds flat vertex buffers and a very simple command list where each command is basically 'please render this range of vertices with this scissor rect', and as I wrote above, generates about 1 draw call per window. Only a new clip-rect (e.g. a scrolling text frame) requires a new draw call. As an example, in my 8-bit emulator, the entire debugging UI, with all windows open (12 windows with a lot of scrollable text, buttons, lists etc...) costs 16 draw calls.
  - c-smile 10y ago
    It depends on what your layout actually is. Just to take "simple" text rendering... When you have just ASCII text rendered with monospace font then it probably OK to do its full layout on each render run - that's really simple. But if you need to render, say, HN page then you'd better compute once and cache glyph positions. And other objects too that need calculations: gradients, tesselated shapes, etc. Check this: http://sciter.com/sciter-and-directx/ http://sciter.com/sciter-and-directx/ That's relatively simple UI rendered directly into DirectX as a batch of precomputed meshes. Ideally you should be able to take best of two worlds: immediate mode graphics and declarative one.
- pandaman 10y ago
  The vast majority of games are very complex GUIs because the entire game is a graphics interface with the user, not just some HUD or menus. Yet most of them run on an immediate mode API. It's funny that you mention this because I remember trying to utilize DirectX RM (retained mode) for a game in late 90s. Even without taking the performance into account (one could say that the implementation was not very optimal) it was a major pain to do anything. One thing I remember vividly: our explosions were static meshes containing all frames of animation and were animated through toggling visibility of different nodes. Luckily that game had been killed by publisher and I did not have to suffer through optimizing its performance.

by ocornut 10y ago

TillE 10y ago

It's an inevitable drawback of the entire concept of an immediate-mode GUI that gets recreated from scratch on every frame. There are major types of optimization which are simply impossible. The vast majority of games use simple GUIs where it won't matter. But if you have a complex or large GUI, you will be eating up significantly more CPU cycles.

ocornut 10y ago
Displaying a few hundreds widgets has absolutely negligible cost if the code is written properly. For large lists they can always be clipped and not submitted at all. With an immediate-mode GUI you can actually handle navigation of a list of one million items whereas more RMGUI would struggle because of all the intermediate data involved. Also, the optimization bottleneck nowadays is mostly programmer/brain time, so having a ten-fold productivity improvements means you can actually create more/better tooling and that has very direct consequence on your software performance. The reality with toolkits like QT is that people write very little amount of tooling with it, because it is so tedious. The cost of that are lost opportunity in improving a game engine and its performances.
flohofwoe 10y ago
In my experience the main problem with performance in UI system is not layout, but draw calls and render state changes. There are some braindead UI solutions that build a hierarchical scene graph for rendering, with each node in the graph costing one draw call. Once you have such a system it doesn't matter whether the higher level parts follow the immediate-mode or non-immediate-mode philosophy, or if the scene graph itself is rebuilt each frame or not, just the render state changes and draw-call overhead will kill performance as soon as you have a few hundred UI elements on screen. Dear Imgui builds flat vertex buffers and a very simple command list where each command is basically 'please render this range of vertices with this scissor rect', and as I wrote above, generates about 1 draw call per window. Only a new clip-rect (e.g. a scrolling text frame) requires a new draw call. As an example, in my 8-bit emulator, the entire debugging UI, with all windows open (12 windows with a lot of scrollable text, buttons, lists etc...) costs 16 draw calls.
- c-smile 10y ago
  It depends on what your layout actually is. Just to take "simple" text rendering... When you have just ASCII text rendered with monospace font then it probably OK to do its full layout on each render run - that's really simple. But if you need to render, say, HN page then you'd better compute once and cache glyph positions. And other objects too that need calculations: gradients, tesselated shapes, etc. Check this: http://sciter.com/sciter-and-directx/ http://sciter.com/sciter-and-directx/ That's relatively simple UI rendered directly into DirectX as a batch of precomputed meshes. Ideally you should be able to take best of two worlds: immediate mode graphics and declarative one.
pandaman 10y ago
The vast majority of games are very complex GUIs because the entire game is a graphics interface with the user, not just some HUD or menus. Yet most of them run on an immediate mode API. It's funny that you mention this because I remember trying to utilize DirectX RM (retained mode) for a game in late 90s. Even without taking the performance into account (one could say that the implementation was not very optimal) it was a major pain to do anything. One thing I remember vividly: our explosions were static meshes containing all frames of animation and were animated through toggling visibility of different nodes. Luckily that game had been killed by publisher and I did not have to suffer through optimizing its performance.