Earlier quoted context omitted.
All these pixels have to be pushed every frame even with classic GUI. The only difference is that it is usually done by the operating system.
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.
Raygui – A simple and easy-to-use immediate-mode GUI library
51–60 of 117 posts
Re: Raygui – A simple and easy-to-use immediate-mode GUI library
#52Earlier quoted context omitted.
All these pixels have to be pushed every frame even with classic GUI. The only difference is that it is usually done by the operating system.
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.
Re: Raygui – A simple and easy-to-use immediate-mode GUI library
#53Re: Raygui – A simple and easy-to-use immediate-mode GUI library
#54I 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…
Re: Raygui – A simple and easy-to-use immediate-mode GUI library
#55Earlier quoted context omitted.
How is: Box( Button( Icon(...) ) ) Weirder than:
Now attach some callbacks. With XML I'm attaching my callbacks via code while defining the UI elsewhere. With pure code, I have to attach the callbacks directly to the object. Theirs a reason you don't just use JavaScript to define React components
The main benefit of most immediate mode guis I've seen is that it's trivial to expose internal values to a ui in one line of code. No callbacks, no looking for the right place in any XML file or similar. Instead you add these lines when you need them and they show up in a ui:
checkbox(&godmode, "Activate Godmode")
slider(&enemy_aggro, "Enemy aggression", 0, 100)Re: Raygui – A simple and easy-to-use immediate-mode GUI library
#56Does anyone care to explain what immediate mode means?
Re: Raygui – A simple and easy-to-use immediate-mode GUI library
#57Related, 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
This is fantastic, it’s a shame this doesn’t have more views. If it’s okay, I submitted it to the hackaday.com tip line.
Re: Raygui – A simple and easy-to-use immediate-mode GUI library
#58Earlier quoted context omitted.
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.
"Immediate mode" just describes the programming model (e.g. how the UI is described with code and how the code reacts to user input), it doesn't tell anything about how rendering happens (or really anything that happens under the hood).
Re: Raygui – A simple and easy-to-use immediate-mode GUI library
#59Does anyone care to explain what immediate mode means?
TLDR: instead of declaring your GUI objects/components ahead of time, and letting a framework render the prepared scene graph (while calling you back when there are user triggered state changes), you just draw the GUI objects yourself in your main loop, just like you draw all your other objects (backgrounds, sprites, models etc).
Re: Raygui – A simple and easy-to-use immediate-mode GUI library
#60Earlier quoted context omitted.
"Immediate mode" just describes the programming model (e.g. how the UI is described with code and how the code reacts to user input), it doesn't tell anything about how rendering happens (or really anything that happens under the hood).
It does imply to some degree that the entire geometry of the UI isn't stored in GPU memory. It's possible to store an entire UI, with text and all, in GPU memory and render it with a single call (e.g. glDrawElements).
Most just don't this (and instead use dynamic buffers which are updated with new data each frame) because the state diffing would complicate the implementation and is usually "not worth it", but they still implement batching within a single frame and reduce the amount of draw calls as much as possible (for instance in Dear ImGui, there's usually one draw call per scroll/clip region so you get away with a handful or at most a few dozen draw calls even for complex UIs).