Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Raygui – A simple and easy-to-use immediate-mode GUI library

github.com

Post reply on HN
Print view View original

101–110 of 117 posts

Re: Raygui – A simple and easy-to-use immediate-mode GUI library

#101

Post by AussieWog93 »

gmueckl wrote: post #99
Adverblessly wrote: post #69

Earlier quoted context omitted.

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…

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 es…

That's not at all true, at least for Dear ImGui.

I reimplemented the text rendering in it at one stage (we needed to support arbitrary unicode strings, specifically file names with CJK characters), drilling all the way down to individual OpenGL calls to get it running [1].

Apart from any driver-level caches, there really is no UI state.

[1] For what it's worth, this was an easier undertaking than simply recompiling Qt.

Re: Raygui – A simple and easy-to-use immediate-mode GUI library

#102

Post by AussieWog93 »

synergy20 wrote: post #19

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 thos…

>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!).

Re: Raygui – A simple and easy-to-use immediate-mode GUI library

#103

Post by CJefferson »

a-priori wrote: post #12

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.

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.

Re: Raygui – A simple and easy-to-use immediate-mode GUI library

#104

Post by AussieWog93 »

quotemstr wrote: post #30
synergy20 wrote: post #19

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 thos…

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 fund…

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.

Re: Raygui – A simple and easy-to-use immediate-mode GUI library

#105

Post by grishka »

a-priori wrote: post #12

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.

Seeing that it uses char* for strings, I'd also assume it doesn't support unicode and thus non-Latin scripts.

Re: Raygui – A simple and easy-to-use immediate-mode GUI library

#106

Post by schleck8 »

a-priori wrote: post #12

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 think egui (Rust) supports screenreaders

Re: Raygui – A simple and easy-to-use immediate-mode GUI library

#107

Post by AussieWog93 »

infogulch wrote: post #40

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…

>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.

Re: Raygui – A simple and easy-to-use immediate-mode GUI library

#108

Post by sunout2 »

grishka wrote: post #105
a-priori wrote: post #12

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.

Seeing that it uses char* for strings, I'd also assume it doesn't support unicode and thus non-Latin scripts.

Raygui supports unicode for input and output.

https://github.com/raysan5/raygui/issues/99

Re: Raygui – A simple and easy-to-use immediate-mode GUI library

#109

Post by throwaway82652 »

cyber_kinetist wrote: post #93
avodonosov wrote: post #85

Earlier quoted context omitted.

The immediate mode gui is largely a myth, IMHO. 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 (r…

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 b…

>complex flexbox layouting, theming, and animations

The only way to implement those things in an immediate mode framework is to cache a lot of state. I haven't found this to be any easier, once the layout becomes complex enough the amount of information that needs to be cached approaches what it would be in retained mode. Because of this I've also found the performance of immediate mode to be very bad. Especially when it involves:

- large pieces of reflowing text (this means no text editors or word processors)

- very large datasets in list/tree/column/grid widgets (this means no database editors or spreadsheets)

- something like a flexbox, css grid or a constraint-solver based layout (this means no responsive layouts)

These are all nice things that don't fit well with those patterns. Without any caching or keying it's functionally equivalent to having a React layout that diffs the entire tree before every redraw.

The main use cases for immediate mode appears to only be quick prototyping, and making debugging tools for games and simulators. That's not bad by any means, but I've never seen one that is able to efficiently do complex layouts with large datasets.

Re: Raygui – A simple and easy-to-use immediate-mode GUI library

#110

Post by gmueckl »

AussieWog93 wrote: post #101
gmueckl wrote: post #99

Earlier quoted context omitted.

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 es…

That's not at all true, at least for Dear ImGui. I reimplemented the text rendering in it at one stage (we needed to support arbitrary unicode strings, specifically file names with CJK characters), drilling all the way down to individual OpenGL calls to get it running [1]. Apart from any driver-level caches, there really is no UI state. [1] For what it's worth, this was an easier undertaking than simply recompiling Q…

What you're saying is copmpletely wrong. ImGUI is transparently creating structs with internal widget state for every slightly more complex widget on the screen. Look at the state structs in imgui_internal.h to get an idea of what I'm talking about, e.g. ImGuiInputTextState or the huge ImGuiWindow structs. The apparent statelessness of immediate mode GUIs is an illusion that is produced by an extra layer of internal logic that manages that state.
Post reply on HN