“This is Rust, running at 60fps.” Immediately below that: “FPS: 18.5”
Snark aside, is it really necessary to render every frame when there have been no I/O events? Maybe redraw only on mouse click / drag, or when the control under the mouse changes?
No, it’s not necessary, but it does make it far, far easier to write the GUI and also easier to write the code using it as long as it doesn’t get too elaborate. The opposite model to an immediate mode GUI is “retained mode GUI”, where you build a data structure representing your GUI, and generally only redraw parts of it that change state; this model is used by Real Gui Libs(tm) like Qt, Cocoa and WinAPI. Imgui’s such as Dear Imgui or Nuklear are particularly popular in gamedev as debug interfaces, since the performance is generally Good Enough and it’s easy to throw them together and modify them.
Another reason why immediate GUIs are popular with games and other 3D visualization tools is that you’re typically dirtying your whole window on every frame and making frames as fast as you can anyway; they’re already pegging your CPU drawing the application, so pushing into that peg a little more for a nice UI library is fine :)
You can have a mix though, where you write all your GUI as if it was immediate mode but then you just pause the render loop when nothing at all is happening.
I find the modern chiasmus from retained mode UI (Win32 et al) and immediate mode graphics (OpenGL 1.x) to immediate mode GUIs (React) and retained mode graphics (modern GL) amusing.
There’s nothing about immediate mode GUIs that requires them to render at 60fps in the absence of input events. Games do this because they naturally have a realtime render loop, but desktop applications don’t and there’s no reason to impose one.
I think you can do immediate mode but then render that through HTML / CSS. You can then style from outside the code with CSS, and submit HTML immediate mode from your code. Keeps the game-code-friendly ergonomics. I was trying this out and it’s actually been kinda fun: https://twitter.com/snikhilesh/status/1275945505168584704?s=21
You can even reuse existing “web components” and whatnot that way. I think I’ll end up building the CSS up from scratch though cuz it’s fun. :D
Edit: I didn’t mean to tear apart this rather minimal demo, I just want to bring awareness to this: If you’re trying to single-handedly replace a native toolkit in 400 commits and a few months of work, you’re not going to do it.
This demo is just like Flash UIs, which were great for games, and terrible for anything else, and which made Web usability hell for a long time. I don’t want to see it happen again.
My favorite part about this demo is how my browser’s keyboard bindings don’t recognize a single element on the page.
My second favorite part about this demo is how when I right-click on the link with the mouse, I cannot copy its URL, nor open it in a new tab.
I’m also a huge fan of how none of the text is selectable, so I cannot copy anything. All the DRM fiends must be creaming their pants right about now.
It is a nice touch that when I send keystrokes directly to the app, it does not react in any way. It reminds me of the minimal toolkit of a low-budget DOS game, or perhaps one that came bundled with my Windows 3.11 Packard Bell in 1994.
A very special behavior, one I could not reproduce easily, is that when I drag out of the window, not only does the mouse-up event not unregister, but the drag event keeps getting re-triggered every time I mouse back into the window, creating some really cool effects, the windows alternating between resizing and moving around.
I also dig the really basic textboxes, only enter and delete text.
All in all, a great show. I starred the project, and look forward to seeing more amazing work from the author.
I see the edit you made to your comment, but as written it still strikes me as unkind. Please remember that there’s a human being on the other end. You don’t know their circumstances, their level of experience, etc. This person works at a game studio, but it could have easily been a newcomer, they could have been proud of their work, and comments like this may discourage them from continuing to learn.
It utilizes circa 30 % of CPU all the time, even if I do not move mouse or even look at that GUI (I am switched to a different desktop looking at htop in Konsole).
I understand that it is development/experimental version, but: do you have any performance goals?
P.S. One mouse wheel step is too small – compared to scrolling in a native GUI or a classic web page on the same computer.
P.P.S. Scrolling in the Scroll area scrolls also the outer window/pane.
CPU hogging might be browser/platform-dependent. I’m also getting around 30% CPU usage when I’m looking at the demo (which isn’t surprising for immediate mode, but I wouldn’t call it lightweight), but it drops as soon as I switch to another tab or desktop. Firefox ESR 68.9.0 on Gentoo.
I tried Firefox and Chromium on GNU/Linux with similar results. But I switched to a different window/desktop. You are right that if I switch to a different tab, the excessive CPU usage disappears.
I admire this individual project. On the other hand, we are moving from the approach of shipping documents with only the content, slightly wrapped up in stylesheets, to a virtual machine running any code at all as the most deployed software ever.
Does this mean we failed at shipping the content and letting the client how to mostly render it?
Does this mean we failed to come-up with an user interface description language?
Does this mean we failed at deploying software to end users so much that the most commonly used approach is shipping an hypervisor that we run software on?
Developers and especially designers may want control down to the pixel over how content and UI are rendered. But some users need the flexibility that the web platform offers, e.g. for accessibility.
Absolutely, but a good chunk of the modern web – including a lot of tools similar to this project (I doubt it’s fair to poke at this one in particular, seeing how it’s just a demo) – is at best sub-optimal in terms of accessibility, if not an outright disaster. For most companies, I doubt that accessibility played a significant role in the shift towards web applications.
In virtually all cases I’ve seen in my career, the move has been motivated by things like easier monetization through a service model, better brand presence and so on. “We can improve our application’s accessibility” is an argument that I’ve rarely been able to use persuasively, whereas “we have total freedom in how we design our application as we are not constrained by each platform’s limitations” is an argument that nobody even needs to make anymore, it’s already well-understood.
Would it qualify as “graceful fallback”? While shipping content, making sure that while disabling everything we get a well-structured plain HTML website?
If Google ever takes this as a criterion in page ranking, this would be a huge lift simplifying the web a lot. That could help crawling as well…
I’m currently porting/modernizing an old (Palm OS) app of mine (ninerpaint) to modern platforms with Rust, using the sdl2 crate. Any chance that I can hook Egui to that (was rolling my own UI framework but quickly realiized that I am not a masochist)?
Not the author of the crate, but it says it can display anywhere where it can get events (sdl2) and print triangles (the openGL context in sdl2?). I’d say it’s doable?
Interesting trial. Personally, I think this kind of UI implementations are going to be the majority of the web in near future. (in 5 years) HTML+CSS will disappear slowly.
CPU consumption can easily be optimized by rendering only on demand. Check state changes and skip rendering if possible. Nowadays almost every UI frameworks are moving to diff-based rendering, and I think this is a convergent evolution.
Personally, I think this kind of UI implementations are going to be the majority of the web in near future. (in 5 years) HTML+CSS will disappear slowly.
If this happens, it will be a nightmare for accessibility.
Honestly I don’t think that can beat Chrome or FF’s rendering engine. DOM+CSS gives a lot of flexibility and is now quite speedy. Now, what I’d like to see is a highly optimised typography and layout engine that supports a sane subset of DOM/CSS and runs at 100+FPS. You could run it in the browser, or you could run it in this highly optimised UI runtime.
50-60FPS on my smartphone (depending on whether the initial dialog is on).
~30 on an old thinkpad.
Looks neat and very responsive (delay). The game demo is also nice (and a refreshing game idea for a demo.)
But please nobody adopt this for everyday stuff ;) No seriously, it’s already annoying how much cpu and memory some tabs hug these days, even though they’re not inside an immediate mode UI.
Heh, it even supports touch scrolling (without inertia though) but the on-screen keyboard doesn’t appear when focusing the textfield (Firefox Preview Android)
“This is Rust, running at 60fps.” Immediately below that: “FPS: 18.5”
Snark aside, is it really necessary to render every frame when there have been no I/O events? Maybe redraw only on mouse click / drag, or when the control under the mouse changes?
No, it’s not necessary, but it does make it far, far easier to write the GUI and also easier to write the code using it as long as it doesn’t get too elaborate. The opposite model to an immediate mode GUI is “retained mode GUI”, where you build a data structure representing your GUI, and generally only redraw parts of it that change state; this model is used by Real Gui Libs(tm) like Qt, Cocoa and WinAPI. Imgui’s such as Dear Imgui or Nuklear are particularly popular in gamedev as debug interfaces, since the performance is generally Good Enough and it’s easy to throw them together and modify them.
Another reason why immediate GUIs are popular with games and other 3D visualization tools is that you’re typically dirtying your whole window on every frame and making frames as fast as you can anyway; they’re already pegging your CPU drawing the application, so pushing into that peg a little more for a nice UI library is fine :)
You can have a mix though, where you write all your GUI as if it was immediate mode but then you just pause the render loop when nothing at all is happening.
I find the modern chiasmus from retained mode UI (Win32 et al) and immediate mode graphics (OpenGL 1.x) to immediate mode GUIs (React) and retained mode graphics (modern GL) amusing.
There’s nothing about immediate mode GUIs that requires them to render at 60fps in the absence of input events. Games do this because they naturally have a realtime render loop, but desktop applications don’t and there’s no reason to impose one.
I think you can do immediate mode but then render that through HTML / CSS. You can then style from outside the code with CSS, and submit HTML immediate mode from your code. Keeps the game-code-friendly ergonomics. I was trying this out and it’s actually been kinda fun: https://twitter.com/snikhilesh/status/1275945505168584704?s=21
You can even reuse existing “web components” and whatnot that way. I think I’ll end up building the CSS up from scratch though cuz it’s fun. :D
It runs at 75fps for me :)
Edit: I didn’t mean to tear apart this rather minimal demo, I just want to bring awareness to this: If you’re trying to single-handedly replace a native toolkit in 400 commits and a few months of work, you’re not going to do it.
This demo is just like Flash UIs, which were great for games, and terrible for anything else, and which made Web usability hell for a long time. I don’t want to see it happen again.
My favorite part about this demo is how my browser’s keyboard bindings don’t recognize a single element on the page.
My second favorite part about this demo is how when I right-click on the link with the mouse, I cannot copy its URL, nor open it in a new tab.
I’m also a huge fan of how none of the text is selectable, so I cannot copy anything. All the DRM fiends must be creaming their pants right about now.
It is a nice touch that when I send keystrokes directly to the app, it does not react in any way. It reminds me of the minimal toolkit of a low-budget DOS game, or perhaps one that came bundled with my Windows 3.11 Packard Bell in 1994.
A very special behavior, one I could not reproduce easily, is that when I drag out of the window, not only does the mouse-up event not unregister, but the drag event keeps getting re-triggered every time I mouse back into the window, creating some really cool effects, the windows alternating between resizing and moving around.
I also dig the really basic textboxes, only enter and delete text.
All in all, a great show. I starred the project, and look forward to seeing more amazing work from the author.
I see the edit you made to your comment, but as written it still strikes me as unkind. Please remember that there’s a human being on the other end. You don’t know their circumstances, their level of experience, etc. This person works at a game studio, but it could have easily been a newcomer, they could have been proud of their work, and comments like this may discourage them from continuing to learn.
It utilizes circa 30 % of CPU all the time, even if I do not move mouse or even look at that GUI (I am switched to a different desktop looking at htop in Konsole).
I understand that it is development/experimental version, but: do you have any performance goals?
P.S. One mouse wheel step is too small – compared to scrolling in a native GUI or a classic web page on the same computer.
P.P.S. Scrolling in the Scroll area scrolls also the outer window/pane.
CPU hogging might be browser/platform-dependent. I’m also getting around 30% CPU usage when I’m looking at the demo (which isn’t surprising for immediate mode, but I wouldn’t call it lightweight), but it drops as soon as I switch to another tab or desktop. Firefox ESR 68.9.0 on Gentoo.
I tried Firefox and Chromium on GNU/Linux with similar results. But I switched to a different window/desktop. You are right that if I switch to a different tab, the excessive CPU usage disappears.
I admire this individual project. On the other hand, we are moving from the approach of shipping documents with only the content, slightly wrapped up in stylesheets, to a virtual machine running any code at all as the most deployed software ever.
Web browsers are going extremely far into replacing the platform they run on.
Does this mean we failed at shipping the content and letting the client how to mostly render it?
Does this mean we failed to come-up with an user interface description language?
Does this mean we failed at deploying software to end users so much that the most commonly used approach is shipping an hypervisor that we run software on?
I don’t think we “failed” – I think “we”, as in the software industry, found out we really don’t want that :).
Developers and especially designers may want control down to the pixel over how content and UI are rendered. But some users need the flexibility that the web platform offers, e.g. for accessibility.
Absolutely, but a good chunk of the modern web – including a lot of tools similar to this project (I doubt it’s fair to poke at this one in particular, seeing how it’s just a demo) – is at best sub-optimal in terms of accessibility, if not an outright disaster. For most companies, I doubt that accessibility played a significant role in the shift towards web applications.
In virtually all cases I’ve seen in my career, the move has been motivated by things like easier monetization through a service model, better brand presence and so on. “We can improve our application’s accessibility” is an argument that I’ve rarely been able to use persuasively, whereas “we have total freedom in how we design our application as we are not constrained by each platform’s limitations” is an argument that nobody even needs to make anymore, it’s already well-understood.
Would it qualify as “graceful fallback”? While shipping content, making sure that while disabling everything we get a well-structured plain HTML website?
If Google ever takes this as a criterion in page ranking, this would be a huge lift simplifying the web a lot. That could help crawling as well…
I did not see it like that, and that would explain a few things, thanks.
I’m currently porting/modernizing an old (Palm OS) app of mine (ninerpaint) to modern platforms with Rust, using the sdl2 crate. Any chance that I can hook Egui to that (was rolling my own UI framework but quickly realiized that I am not a masochist)?
Not the author of the crate, but it says it can display anywhere where it can get events (sdl2) and print triangles (the openGL context in sdl2?). I’d say it’s doable?
Check out iced, you can definitely hook it to anything, it’s very modular.
Interesting trial. Personally, I think this kind of UI implementations are going to be the majority of the web in near future. (in 5 years) HTML+CSS will disappear slowly.
CPU consumption can easily be optimized by rendering only on demand. Check state changes and skip rendering if possible. Nowadays almost every UI frameworks are moving to diff-based rendering, and I think this is a convergent evolution.
If this happens, it will be a nightmare for accessibility.
That’s sad and true. And also nightmare for non-English users as proper IME support is unlikely to come together.
Honestly I don’t think that can beat Chrome or FF’s rendering engine. DOM+CSS gives a lot of flexibility and is now quite speedy. Now, what I’d like to see is a highly optimised typography and layout engine that supports a sane subset of DOM/CSS and runs at 100+FPS. You could run it in the browser, or you could run it in this highly optimised UI runtime.
Sciter, rmlui
Thanks, never heard of them!
50-60FPS on my smartphone (depending on whether the initial dialog is on). ~30 on an old thinkpad. Looks neat and very responsive (delay). The game demo is also nice (and a refreshing game idea for a demo.)
But please nobody adopt this for everyday stuff ;) No seriously, it’s already annoying how much cpu and memory some tabs hug these days, even though they’re not inside an immediate mode UI.
Heh, it even supports touch scrolling (without inertia though) but the on-screen keyboard doesn’t appear when focusing the textfield (Firefox Preview Android)