3 ms·

I don’t think that an imgui app will eat more resources than a comparable electron app. Thus the Performance Argument against any IMGUI is pretty pointless.

by frnkng 7y ago

theamk 7y ago
I disagree. With all downsides of electron, it does not generally re-layout and re-render entire screen on any mouse move. IMGUI does. So while Electron will lose in memory/disk used, IMGUI will lose in CPU usage (battery life) once the software is complex enough.
- tokyodude 7y ago
  I disagree with your disagreement :) Electron (and nearly all retained mode GUIs) will execute 10x more code trying not to execute the rendering code. Just skipping all that checking and jumping to the rendering code is arguably a win in many many cases. To put some empirical data on it, game devs use ImGUIs because they keep up with perf where as that 10x overhead of retained mode guis creating gui objects, deleting gui objects, marshaling data into and out of gui objects, adding and removing event handlers and callbacks, and then trying to write a bunch more code to optimize all of that never leads to a GUI that is performant enough for the GUIs needed for game dev. I think if you check actual apps, especially phone apps, you'll find it's not so clear which one wins. Phone apps almost always move in relation to the users fingers meaning the screen is being re-rendered. Usually new GUI elements are moving on and off the top/bottom of the screen. The overhead of creating/deleting/managing those objects is arguably greater than just re-rendering. The screen is already going to be re-rendered. At best you're getting a few cached textures from your retained mode gui all at the expensive of managing GUI objects. For desktop apps it really depends on the app. It's got nothing to do with the complexity of the UI and everything to do with what the app does. A text editor might be a win for a retained mode GUI. Photoshop/Maya it's less clear. For example Unity is ImGUI and has very complex UI. Much of the UI has to respond in realtime to the state of the user's document that is changing constantly.
  - userbinator 7y ago
    Phone apps almost always move in relation to the users fingers meaning the screen is being re-rendered. I'm not really familiar with the mobile platforms, but given their reliance on battery power, I hope(!) that scrolling is done mostly in hardware and actual re-rendering happens only for areas beyond the scrolling boundary. Of course you will need to re-render when the actual content changes, but not with just scrolling. To put some empirical data on it, game devs use ImGUIs because they keep up with perf where as that 10x overhead of retained mode guis creating gui objects, deleting gui objects, marshaling data into and out of gui objects, adding and removing event handlers and callbacks, and then trying to write a bunch more code to optimize all of that never leads to a GUI that is performant enough for the GUIs needed for game dev. That sounds more like an implementation/application problem --- overuse of OOP or an application where too much is constantly changing --- rather than an inherent inefficiency of retained mode. The Windows native GUI, since Win16 in Windows 1.0, was basically designed for retained mode. Immediate mode is more common in games because it's more suited to that application.
  - theamk 7y ago
    > Electron (and nearly all retained mode GUIs) will execute 10x more code trying not to execute the rendering code. Just skipping all that checking and jumping to the rendering code is arguably a win in many many cases. How do you figure? Rendering a single Truetype letter will have dozens of conditional branches, use complex floating point math, and touch tens of kilobytes of cache. And there are many thousands of them in the GUI. Even if you have rendered cache, there is still lots of memory pressure copying data back and forth. Compared to that, retained mode GUIs should be much more efficient. Even 50 checks are nothing compared to ability to void rendering one line. Note this is all predicated on screen being mostly unchanging. For example, as I am typing this comment, everything is stationary except for a single line where I am typing. > The screen is already going to be re-rendered. This is the key! As you said, if you have to re-render whole screen anyway, then retained mode GUIs will have to maintain draw state and re-render every element every time anyway -- a strictly worse performance. But most of the regular apps, like editors and chat clients and web browsers, do not re-render whole screen every time. They only do one thing at a time. For an empirical evidence, look at WinAPI design: this is a retained mode GUI, with lots of effort dedicated to figuring out invalidated rectangles and which controls need to be rendered. This was the only way to make a GUI which is performant enough.
martin_ky 7y ago
Electron is not exactly an epitome of a resource efficient framework either. If I was to compare efficiency, I’d choose a native baseline, such as the X window system or WinAPI. Granted, these APIs are low level and not as rich in features. Typically, the user calls some sort of “mark as dirty” function to mark a region of the window to be updated on the next refresh cycle, thus not wasting resources on portions of the screen that were not touched.

I don’t think that an imgui app will eat more resources than a comparable electron app. Thus the Performance Argument against any IMGUI is pretty pointless.

by frnkng 7y ago

I don’t think that an imgui app will eat more resources than a comparable electron app. Thus the Performance Argument against any IMGUI is pretty pointless.

theamk 7y ago

I disagree. With all downsides of electron, it does not generally re-layout and re-render entire screen on any mouse move. IMGUI does. So while Electron will lose in memory/disk used, IMGUI will lose in CPU usage (battery life) once the software is complex enough.

tokyodude 7y ago
I disagree with your disagreement :) Electron (and nearly all retained mode GUIs) will execute 10x more code trying not to execute the rendering code. Just skipping all that checking and jumping to the rendering code is arguably a win in many many cases. To put some empirical data on it, game devs use ImGUIs because they keep up with perf where as that 10x overhead of retained mode guis creating gui objects, deleting gui objects, marshaling data into and out of gui objects, adding and removing event handlers and callbacks, and then trying to write a bunch more code to optimize all of that never leads to a GUI that is performant enough for the GUIs needed for game dev. I think if you check actual apps, especially phone apps, you'll find it's not so clear which one wins. Phone apps almost always move in relation to the users fingers meaning the screen is being re-rendered. Usually new GUI elements are moving on and off the top/bottom of the screen. The overhead of creating/deleting/managing those objects is arguably greater than just re-rendering. The screen is already going to be re-rendered. At best you're getting a few cached textures from your retained mode gui all at the expensive of managing GUI objects. For desktop apps it really depends on the app. It's got nothing to do with the complexity of the UI and everything to do with what the app does. A text editor might be a win for a retained mode GUI. Photoshop/Maya it's less clear. For example Unity is ImGUI and has very complex UI. Much of the UI has to respond in realtime to the state of the user's document that is changing constantly.
- userbinator 7y ago
  Phone apps almost always move in relation to the users fingers meaning the screen is being re-rendered. I'm not really familiar with the mobile platforms, but given their reliance on battery power, I hope(!) that scrolling is done mostly in hardware and actual re-rendering happens only for areas beyond the scrolling boundary. Of course you will need to re-render when the actual content changes, but not with just scrolling. To put some empirical data on it, game devs use ImGUIs because they keep up with perf where as that 10x overhead of retained mode guis creating gui objects, deleting gui objects, marshaling data into and out of gui objects, adding and removing event handlers and callbacks, and then trying to write a bunch more code to optimize all of that never leads to a GUI that is performant enough for the GUIs needed for game dev. That sounds more like an implementation/application problem --- overuse of OOP or an application where too much is constantly changing --- rather than an inherent inefficiency of retained mode. The Windows native GUI, since Win16 in Windows 1.0, was basically designed for retained mode. Immediate mode is more common in games because it's more suited to that application.
- theamk 7y ago
  > Electron (and nearly all retained mode GUIs) will execute 10x more code trying not to execute the rendering code. Just skipping all that checking and jumping to the rendering code is arguably a win in many many cases. How do you figure? Rendering a single Truetype letter will have dozens of conditional branches, use complex floating point math, and touch tens of kilobytes of cache. And there are many thousands of them in the GUI. Even if you have rendered cache, there is still lots of memory pressure copying data back and forth. Compared to that, retained mode GUIs should be much more efficient. Even 50 checks are nothing compared to ability to void rendering one line. Note this is all predicated on screen being mostly unchanging. For example, as I am typing this comment, everything is stationary except for a single line where I am typing. > The screen is already going to be re-rendered. This is the key! As you said, if you have to re-render whole screen anyway, then retained mode GUIs will have to maintain draw state and re-render every element every time anyway -- a strictly worse performance. But most of the regular apps, like editors and chat clients and web browsers, do not re-render whole screen every time. They only do one thing at a time. For an empirical evidence, look at WinAPI design: this is a retained mode GUI, with lots of effort dedicated to figuring out invalidated rectangles and which controls need to be rendered. This was the only way to make a GUI which is performant enough.

martin_ky 7y ago

Electron is not exactly an epitome of a resource efficient framework either. If I was to compare efficiency, I’d choose a native baseline, such as the X window system or WinAPI. Granted, these APIs are low level and not as rich in features. Typically, the user calls some sort of “mark as dirty” function to mark a region of the window to be updated on the next refresh cycle, thus not wasting resources on portions of the screen that were not touched.