Related, check out raylib, the rendering/game engine made by the same author!
I’ve used Raylib and raygui on a few RPi based projects and recommend it. It’s a really simple, intuitive way to get an OpenGL-based UI running. Good alternative to web-based UIs because it has similar simplicity but runs on devices with lower specs. I built this pinball machine with raylib: https://youtu.be/iiBn7FVzlcc
Raylib is great and one of my preferred libraries for writing emulators in. But I will say if you’re expecting something like imgui or nuklear with Raygui, it’s not nearly as advanced or usable.
Before you start picking up a library like this, keep in mind that no immediate-mode GUI library I'm aware of (including this one from what I can see in the source code) has support for assistive technologies such as screen readers.
To them the whole UI is one big black box, so your program is completely useless to anyone with a wide range of disabilities.
I can also report some modest progress on my own work on accessibility of immediate-mode GUIs. I have a branch of the Rust egui library [1] that has basic accessibility on Windows using my AccessKit project [2]. I do have a long way to go to make this fully usable and ready to submit upstream, especially when taking non-Windows platforms into account.
Do operation systems have APIs, so the program can send them what is on the screen? I mean just description like: There is the button with title "Push me" in the rectangle(50, 50, 100, 70), etc.
Even systems like Qt, where things are drawn using non-native widgets support that (I was long proponent of wxWidgets, because I thought assistive tech is only support only if you use native widgets. The idea of API where you explain what you are showing, and how to interact with it never came to my mind, but with ARIA - like any browser that's the way to go).
Not only that, but I thhink assistive tech should allow you do to easier GUI testing too, but haven't digged into that idea yet (probably folks already are)
Yes, OSes have APIs. Another commenter talked about the Mac one, Linux has AT-SPI and Windows has MSAA (historic) and UIA. If I'm not mistaken, they generally are about representing the UI as a tree of items as this is what the accessibility hardware expects / works best with.
Yes. I don’t know about Windows but I know that for OSX you need to implement the NSAccessibility protocol in AppKit. This gives you a way to describe the hierarchy of the UI and to notify the system of important changes.
I've been using an immediate mode api that generates html elements in web, so that you do get the things that html offers. I basically have a thin wrapper around http://google.github.io/incremental-dom/ (I'm using it from wasm) -- calling it per frame has actually been reasonable perf-wise.
Thanks for making the post I was coming to make :)
While it's popular to mock electron, it does make it easy to make accessible cross-platform apps, whereas most of the "minimal alternatives" are entirely inaccessible.
I have seen quite often 'immediate mode gui' on HN and elsewhere these days,I rarely do GUI myself, where are these im-gui's use cases? gaming only? or some embedded boards with limited resources can benefit to draw some pixels on a small LCD for a simple GUI(even that people are more likely use some light-weight x11 like libraries instead of im-gui library)?
Other than game-development why is im-gui better than those normal widget kits we are relatively more familiar with: gtk, qt,etc)? or im-gui is specifically for gaming coding?
IMO The main benefit of immediate mode GUI is that (unlike "normal widget kits"), the data required to "drive" the widgets is not actually owned by the widgets themselves, making widgets controlled directly by the "program's" data. You make some sort of change to the program's data and it is immediately reflected on the screen. This is as opposed to the "normal widget kits" where you need some "glue" to reflect those changes for example maybe you need to let the widget know its contents were updated and it needs to redraw or redo its layout.
This makes it easier to create certain types of UIs where the main interaction is to modify some data structure directly, which is how many simple tools behave.
The unfortute truth to these toolkits is that they need to keep a ton of shadow state internally and diff that to the data coming in with each new frame. The most trivial example would be a button. The user redeclares this button each frame as if it was new, but the UI must unify that to a single persistent button instance to get the stateful button behavior right. Every interactive control needs similar logic. In essence you trade tailor-made, performant UI update code with an implicit, complicated and expensive semi-"transparent" generic update logic. It works for simple UI patterns with not too much data in the controls, but anything more heavy will r7n into problems.
Many people at a certain point in their careers become infatuated with the idea of making a "small", "simple", and "opinionated" component free from legacy "BS". They have the skill to implement the core of that component but lack the wisdom and humility to understand that the "BS" complexity exists for good reasons, that their "small" component is subject to those reasons, and that they haven't actually found a fundamentally better approach that avoids the "BS", but merely skipped the hard parts of software engineering.
You just have to let people go through this phase. You should nod, smile, and compliment them on the economy of their vision.
This phase hones skills people need for more serious endeavors. Butt God help you if you actually use one of these "small" systems in production!
Immediate mode is generally used for quick and dirty developer tools. It's rarely used for user-facing UI. You're free to waste your time carefully architecting an MVC application any time you want a few text boxes and sliders to fiddle with something. Microsoft, Google, Nvidia, Valve, Id, Blizzard, Ubisoft will continue to use immediate mode where they deem it useful, in spite of your advice.
Apparently you know the feeling when a competitor comes up and do 80% of what you're doing for half the cost (in dev time, memory weight, etc.). Hell, it still feels unfair even when it's a coworker who gets tasked with redoing (usually using some trendy new stuff) the system you've been maintaining for so long and know by heart, and that you've dreamed to rewrite for an equally long time.
You comfort yourself by saying they will run into the same problems that just wait their time in a dark corners of software or hardware. But they generally are in a much better position, with their smaller and simpler software, to deal with it than with old software.
What your heuristic may be accurate in the general sense, it's absolutely not the case for ImGUIs. I've used the technology on a real commercial product before and it was vastly superior to the old way of doing things.
The "BS" complexity of retained-mode GUIs, as you suggested, is not really BS but the logical result of using a client/server model. That said, for the average desktop application (where all necessary state is local to the user's own machine) this model really is a poor fit and ImGUIs shine.
A lot of the evangelism comes from the fact that many more conservative devs still insist on using the more complex client/server retained-mode paradigm, even when immediate-mode is more suitable to the task at hand.
>Other than game-development why is im-gui better than those normal widget kits we are relatively more familiar with: gtk, qt,etc)?
I was tasked with using both types of frameworks back in my old job.
ImGui eliminates entire classes of bugs related to state synchronisation, and was much easier to make performant because it was overall simpler[1].
It's also much simpler to customise, as widgets are nothing more than functions that draw graphics according to a couple of input variables.
I think a lot of people get confused, as they think ImGuis mean redrawing every asset every frame and therefore performance should be bad. In practice, though, there are driver-side caches and it's absolutely excellent to both work with and use the results of.
[1] While in theory retained-mode GUIs should be as performant as ImGuis or better, in practice it's much easier in retained-mode to accidentally perform an expensive action multiple times in a row in response to a single user interaction. Just tick "select all" on a WordPress page with 100+ elements and you'll see it immediately (well, immediately after several billion cycles have passed anyway!).
The concept of gui fully controlled by program data works well for interfaces consisting of a single button. As soon as we have two buttons, each button has a position, and the positions is the data of the gui itself (retained data), not of the program.
Imagine a multi-tab interface - which tab is currently active and has its controls drawn is the property of the gui (retained data), again.
An action that can be invoked through a menu and can also be added to a toolbar. The toolbar can be expanded or collapsed. Again, that's data of the gui itself (of the view), not of the program (the model).
The currently focused button should be highlighted somehow - the property of the gui again.
Selected elements of a list (they should be highlighted). Expanded/collapsed state of a tree widget nodes. Scroll positions.
So, the immediate mode guis are interesting and somewhat liberating because they demonstrate one can easily build simple ui without complex widget libs, but the results are limited, and very soon stop being really immediate mode. When evolving, they become reinvented wheels of retained mode guis.
All of these functionalities that you have described can b e easily implemented in an immediate-mode UI framework, and in my opinion much easily than retained-mode UI frameworks. (I know this because I have used Dear IMGUI extensively, and have done almost all of the things you’ve said).
I think you’re arguing with some fundamental “philosophical” stance on what data should be owned by the user and what data should be owned by the GUI. But I feel that pragmatically immediate-mode GUIs are the most efficient at creating complex interfaces (like the ones you have described). The parts where IMGUi are lacking is in complex flexbox layouting, theming, and animations, which isn’t required in editor-like applications for professionals but might matter with end-user applications.
It's (more or less) just a different approach to describe a UI through code which does away with objects, event handlers or data binding. Very convenient for purely code driven UI development.
Immediate mode GUIs can be used for almost anything that retained mode GUI toolkits (GTK, Qt) can be used for. It removes a lot of the overhead and boilerplate to speed up development.
very cool. there are already immediate mode libs with a focus on tools. what i’m more interested in is really great gui libs that make architecting multimedia or audio applications easy without requiring me to learn and use game engines. ideally on top of opengl(es) and linux (arm) support. i am thinking about applications where you want cooler UI effects and UX than what we are all used to, like what you sometimes see in games. i just don’t want to do all the drawing myself and don’t want to use game engines. stuff like qt is too heavyweight and too much traditional UI focused. most UI frameworks also have little support built in for advanced producer/consumer or multithreading/work load balancing scenarios and expect you to roll all that stuff yourself over and over.
JUCE is the best option. Shopify came out with React Native Skia, which allows you to draw whatever you need. You can also use Skia directly but it's only a drawing library. I wanted to use something like IMGUI but it's hard to theme and not designed for consumer products. This raygui looks cool but it's bitmap fonts which is no good for i18n.
Edit: Looks like it uses real fonts it just includes a crappy one. I'll have to take a closer look at this.
Immediate mode GUIs are usually pretty inefficient. I wouldn't use it as a permanent solution in a product. More like a quick way to add controls to avoid having to close the app and edit a config file, or recompile with different params.
Usually you want app GUIs with a style that matches the rest of the apps. Though mobile kinda changed that. I don't know of a performant UI framework for building non traditional desktop apps.
Cocoa and CoreAnimation on the Mac allow you to apply arbitrary CoreImage filters to UI elements (not just images) and you can even write your own filters using the Metal shading language (though that’s basically doing a lot of the drawing yourself).
Unfortunately this doesn’t work on iOS (probably for power consumption reasons). Apple does have some filters for things like Gaussian blurs, but they are a private API.
The joy of immediate mode guis is that you don't have to register callbacks or manually modify (for example) the visibility of elements in response to some action. Instead you do:
if checkbox(&show_debug, "Show debugging features") {
if button("Run some test") {
test()
The evolution of HTML and CSS clearly shows that HTML isn't suited to describe a interface without massive hints to a rendering engine to manipulate it
There has been a recent explosion of immediate-mode GUIs recently, but I'm skeptical that an immediate-mode solution can cover our GUI needs now and into the future.
High refresh rate screens are a reality so you only have 3-6ms to render each frame, as well as high resolution screens at 4k-8k. That's a lot of pixels to push with a CPU on every frame. As another comment points out we also need accessibility. I would generalize this need as "GUIs need to be reinterpretable", this need is not limited to those with disabilities and such a capability can be useful to anyone that wants to customize, automate, and integrate their digital tools.
Are immediate-mode GUIs up to the task? What is driving their authors to pursue this design? Why aren't they choosing a declarative design?
I don't get your point here. What's the problem with high refresh rates? Games deal with it no problem, and they do way more complicated stuff than a UI with a bunch of buttons and text.
> Are immediate-mode GUIs up to the task?
Yes, there's no reason why imgui's can't do any of that.
> What is driving their authors to pursue this design?
To name a few: Ridiculous bloat and complicated development with things like Qt. No real GUI framework provided by Microsoft apart of their 4-5 half-abandoned offerings.
Also imgui is way simpler to wrap your head around. It's just straight up function calls with no complicated abstractions.
> Why aren't they choosing a declarative design?
Why should it be declarative though? imgui code looks fairly declarative when you read it and it's easy to understand what UI events cause changes
>What is driving their authors to pursue this design?
The fact that it requires an order of magnitude less code to do functionally the same thing as traditional toolkits.
>Why aren't they choosing a declarative design?
Because they aren't trying to build a native, standalone desktop application. Declarative design makes little sense for quick and dirty developer tools that just need to directly view and modify simple data structures.
>That's a lot of pixels to push with a CPU on every frame.
This is a common misconception.
At least with Dear ImGui, all of the actual rendering is performed by the graphics driver, which has a cache.
So, while you may have to queue 100 "render texture" calls every frame, there's no real difference between ImGUI and retained-mode when it comes to the actual frames being rendered.
God the notion that declarative design will somehow fix everything and is the end all be all needs to go away. As people grow more experienced with programming they want more control over the flow of their program, so they can focus on fixing the bugs instead of playing the abstraction game to fix the (internal) bugs, if they can at all.
> Are immediate-mode GUIs up to the task?
Enough for companies like Unity/UE4 to sponsor the github projects.
The advantage of a declarative design is that it can be accelerated by the GPU which has a much better scaling computational architecture to serve this need.
Readit News
I’ve used Raylib and raygui on a few RPi based projects and recommend it. It’s a really simple, intuitive way to get an OpenGL-based UI running. Good alternative to web-based UIs because it has similar simplicity but runs on devices with lower specs. I built this pinball machine with raylib: https://youtu.be/iiBn7FVzlcc
To them the whole UI is one big black box, so your program is completely useless to anyone with a wide range of disabilities.
Disclaimer: I'm the author.
[1]: https://github.com/mwcampbell/egui/tree/accesskit
[2]: https://github.com/AccessKit/accesskit
Or are there any "screen reader" libraries?
Not only that, but I thhink assistive tech should allow you do to easier GUI testing too, but haven't digged into that idea yet (probably folks already are)
On GNU/Linux, I think the only thing that exists in the Gtk+ features that were originally sponsored by Sun.
While it's popular to mock electron, it does make it easy to make accessible cross-platform apps, whereas most of the "minimal alternatives" are entirely inaccessible.
https://github.com/raysan5/raygui/issues/99
Other than game-development why is im-gui better than those normal widget kits we are relatively more familiar with: gtk, qt,etc)? or im-gui is specifically for gaming coding?
This makes it easier to create certain types of UIs where the main interaction is to modify some data structure directly, which is how many simple tools behave.
You just have to let people go through this phase. You should nod, smile, and compliment them on the economy of their vision. This phase hones skills people need for more serious endeavors. Butt God help you if you actually use one of these "small" systems in production!
You comfort yourself by saying they will run into the same problems that just wait their time in a dark corners of software or hardware. But they generally are in a much better position, with their smaller and simpler software, to deal with it than with old software.
The "BS" complexity of retained-mode GUIs, as you suggested, is not really BS but the logical result of using a client/server model. That said, for the average desktop application (where all necessary state is local to the user's own machine) this model really is a poor fit and ImGUIs shine.
A lot of the evangelism comes from the fact that many more conservative devs still insist on using the more complex client/server retained-mode paradigm, even when immediate-mode is more suitable to the task at hand.
I was tasked with using both types of frameworks back in my old job.
ImGui eliminates entire classes of bugs related to state synchronisation, and was much easier to make performant because it was overall simpler[1].
It's also much simpler to customise, as widgets are nothing more than functions that draw graphics according to a couple of input variables.
I think a lot of people get confused, as they think ImGuis mean redrawing every asset every frame and therefore performance should be bad. In practice, though, there are driver-side caches and it's absolutely excellent to both work with and use the results of.
[1] While in theory retained-mode GUIs should be as performant as ImGuis or better, in practice it's much easier in retained-mode to accidentally perform an expensive action multiple times in a row in response to a single user interaction. Just tick "select all" on a WordPress page with 100+ elements and you'll see it immediately (well, immediately after several billion cycles have passed anyway!).
The concept of gui fully controlled by program data works well for interfaces consisting of a single button. As soon as we have two buttons, each button has a position, and the positions is the data of the gui itself (retained data), not of the program.
Imagine a multi-tab interface - which tab is currently active and has its controls drawn is the property of the gui (retained data), again.
An action that can be invoked through a menu and can also be added to a toolbar. The toolbar can be expanded or collapsed. Again, that's data of the gui itself (of the view), not of the program (the model).
The currently focused button should be highlighted somehow - the property of the gui again.
Selected elements of a list (they should be highlighted). Expanded/collapsed state of a tree widget nodes. Scroll positions.
So, the immediate mode guis are interesting and somewhat liberating because they demonstrate one can easily build simple ui without complex widget libs, but the results are limited, and very soon stop being really immediate mode. When evolving, they become reinvented wheels of retained mode guis.
I think you’re arguing with some fundamental “philosophical” stance on what data should be owned by the user and what data should be owned by the GUI. But I feel that pragmatically immediate-mode GUIs are the most efficient at creating complex interfaces (like the ones you have described). The parts where IMGUi are lacking is in complex flexbox layouting, theming, and animations, which isn’t required in editor-like applications for professionals but might matter with end-user applications.
It’s can be such a fast and light way to work. Get this thing done. And move on to the next thing.
To me it’s just a valuable addition to our toolbox and our quest to use the right tool for the right job.
It is like in games, everyone ends up implementing their own scene graph, while asserting they don't need the one offered by retained mode APIs.
Edit: Looks like it uses real fonts it just includes a crappy one. I'll have to take a closer look at this.
Usually you want app GUIs with a style that matches the rest of the apps. Though mobile kinda changed that. I don't know of a performant UI framework for building non traditional desktop apps.
Unfortunately this doesn’t work on iOS (probably for power consumption reasons). Apple does have some filters for things like Gaussian blurs, but they are a private API.
Then you do something like rootGUI.Query("elementID").RegisterCallback( e => otherFunc(e));
Defining the UI via code becomes cumbersome, stuff like adding attributes, etc
Deleted Comment
High refresh rate screens are a reality so you only have 3-6ms to render each frame, as well as high resolution screens at 4k-8k. That's a lot of pixels to push with a CPU on every frame. As another comment points out we also need accessibility. I would generalize this need as "GUIs need to be reinterpretable", this need is not limited to those with disabilities and such a capability can be useful to anyone that wants to customize, automate, and integrate their digital tools.
Are immediate-mode GUIs up to the task? What is driving their authors to pursue this design? Why aren't they choosing a declarative design?
> Are immediate-mode GUIs up to the task?
Yes, there's no reason why imgui's can't do any of that.
> What is driving their authors to pursue this design?
To name a few: Ridiculous bloat and complicated development with things like Qt. No real GUI framework provided by Microsoft apart of their 4-5 half-abandoned offerings.
Also imgui is way simpler to wrap your head around. It's just straight up function calls with no complicated abstractions.
> Why aren't they choosing a declarative design?
Why should it be declarative though? imgui code looks fairly declarative when you read it and it's easy to understand what UI events cause changes
The fact that it requires an order of magnitude less code to do functionally the same thing as traditional toolkits.
>Why aren't they choosing a declarative design?
Because they aren't trying to build a native, standalone desktop application. Declarative design makes little sense for quick and dirty developer tools that just need to directly view and modify simple data structures.
This is a common misconception.
At least with Dear ImGui, all of the actual rendering is performed by the graphics driver, which has a cache.
So, while you may have to queue 100 "render texture" calls every frame, there's no real difference between ImGUI and retained-mode when it comes to the actual frames being rendered.
> Are immediate-mode GUIs up to the task? What is driving their authors to pursue this design? Why aren't they choosing a declarative design
Immediate mode UIs make managing state much easier, and avoids callbacks for event processing. That alone is worth it in my opinion.
> Are immediate-mode GUIs up to the task?
Enough for companies like Unity/UE4 to sponsor the github projects.