3 ms·

Immediate rendering consumes an insane amount of CPU.

stephc_int13 6y ago
Not in my book. I am running a prototype immediate mode gui that I built for my yet unreleased engine and the frame time is staying below 500ns for a fullscreen app with many widgets and layers. The whole thing is built on C + Vulkan but is not entirely optimized yet. And this is running on a decent but not extremely fast computer. (An Intel NUC from 2018)
- cycloptic 6y ago
  Now take that same code and run it on a mobile device. Can you say for certain that it's making optimal use of power? And if not, what changes would you have to make so it does?
  - stephc_int13 6y ago
    I'll do that later but I don't think it will lead to extreme CPU consumption. There are many ways to improve performances of idle/almost idle ui. Caching can be useful for large blocks of text as it tend to be the slowest thing to render. But it is preferable to incrementally optimize/add complexity and check assumptions and not make large architectural decisions ahead of time. One way to reason about it is to think in terms of pure data transformations.
    - cycloptic 6y ago
      If you're caching data, you now have stored state and it's no longer a pure data transformation. You will run into these performance problems with any large data set, not just blocks of text.
- adamnemecek 6y ago
  Can I see a screenshot?
  - stephc_int13 6y ago
    I plan to publish several articles about my engine later this year, but I am not ready to show it yet.
bsder 6y ago
Only if you render at 60Hz/120Hz/etc. like games do. If you have a static UI, you can skip rendering frames until "something" happens. That's going to burn no more power than a retained-mode UI. Sure, the immediate mode UI may redraw 100,000 triangles vs the retained-mode 100 triangles. However, that's just not a bottleneck on practically every device nowadays. And I doubt that the difference is that stark as rendering scaled text properly is still just egregiously expensive in terms of computation. However, everybody nowadays has to "ANIMATE! <jazzhands>" so you're rendering 60Hz anyway irrespective of type of UI. And if animation is required by application (film editor, digital audio workstation, etc.) it's not clear that you really can do anything other than immediate mode. Do note how many of those kinds of programs wrote their own GUI over the years--that says something. One thing that people don't mention is that immediate-mode UI's tend not to suffer from as many synchronization issues and retained glitches as retained-mode UI's do. Even if you don't get the update correct in an immediate-mode UI, the next frame the error goes away. In a "retained-mode" UI your widget needs to "refresh", which may not happen except in very rare circumstances. I have had to grab the corner and adjust a window size a couple of pixels innumerable times in order to clear UI glitches over the years. I should probably comment about threading and the "UI Master Thread", but I don't think I've seen a good example of an immediate-mode UI running multi-threaded, yet. You probably need Vulkan to even have a hope of pulling that off (OpenGL is notoriously multi-thread hostile).

Not in my book. I am running a prototype immediate mode gui that I built for my yet unreleased engine and the frame time is staying below 500ns for a fullscreen app with many widgets and layers. The whole thing is built on C + Vulkan but is not entirely optimized yet. And this is running on a decent but not extremely fast computer. (An Intel NUC from 2018)

cycloptic 6y ago
Now take that same code and run it on a mobile device. Can you say for certain that it's making optimal use of power? And if not, what changes would you have to make so it does?
- stephc_int13 6y ago
  I'll do that later but I don't think it will lead to extreme CPU consumption. There are many ways to improve performances of idle/almost idle ui. Caching can be useful for large blocks of text as it tend to be the slowest thing to render. But it is preferable to incrementally optimize/add complexity and check assumptions and not make large architectural decisions ahead of time. One way to reason about it is to think in terms of pure data transformations.
  - cycloptic 6y ago
    If you're caching data, you now have stored state and it's no longer a pure data transformation. You will run into these performance problems with any large data set, not just blocks of text.
adamnemecek 6y ago
Can I see a screenshot?
- stephc_int13 6y ago
  I plan to publish several articles about my engine later this year, but I am not ready to show it yet.

bsder 6y ago

Only if you render at 60Hz/120Hz/etc. like games do. If you have a static UI, you can skip rendering frames until "something" happens. That's going to burn no more power than a retained-mode UI. Sure, the immediate mode UI may redraw 100,000 triangles vs the retained-mode 100 triangles. However, that's just not a bottleneck on practically every device nowadays. And I doubt that the difference is that stark as rendering scaled text properly is still just egregiously expensive in terms of computation. However, everybody nowadays has to "ANIMATE! <jazzhands>" so you're rendering 60Hz anyway irrespective of type of UI. And if animation is required by application (film editor, digital audio workstation, etc.) it's not clear that you really can do anything other than immediate mode. Do note how many of those kinds of programs wrote their own GUI over the years--that says something. One thing that people don't mention is that immediate-mode UI's tend not to suffer from as many synchronization issues and retained glitches as retained-mode UI's do. Even if you don't get the update correct in an immediate-mode UI, the next frame the error goes away. In a "retained-mode" UI your widget needs to "refresh", which may not happen except in very rare circumstances. I have had to grab the corner and adjust a window size a couple of pixels innumerable times in order to clear UI glitches over the years. I should probably comment about threading and the "UI Master Thread", but I don't think I've seen a good example of an immediate-mode UI running multi-threaded, yet. You probably need Vulkan to even have a hope of pulling that off (OpenGL is notoriously multi-thread hostile).