Live data from Hacker News

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

github.com

51–60 of 117 posts

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

#51

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.

Both declarative and imperative UI frameworks benefit just fine from GPU acceleration, that's orthogonal to the underlying drawing mechanism

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

#52

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.

"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

#54

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…

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.

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

#55

Earlier 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

You're in the wrong thread. :-)

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

#57

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

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.

Thanks! A little more detail at https://www.chrisdalke.com/projects/mini-pinball-machine/, and the Raylib-based code is on GitHub: https://github.com/chrisdalke/mini-pinball-machine

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

#58

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

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

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

#59

Does anyone care to explain what immediate mode means?

See https://en.wikipedia.org/wiki/Immediate_mode_(computer_graph... , and https://en.wikipedia.org/wiki/Immediate_mode_GUI .

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

#60
post #58

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

...and those GPU buffers need to be rebuilt as soon as anything in the UI changes. An immediate mode UI could just as well track state changes and only rebuild GPU buffers if needed.

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

Post reply on HN