Hacker News Reader

Comment by infogulch | Hacker News Reader

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?

View on HN

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.

With intelligent frame pacing you can sacrifice, say, a frame of input latency to sustain high frame rates. See https://raphlinus.github.io/ui/graphics/gpu/2021/10/22/swapc....

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

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.

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

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

This doesn't make any sense. GPUs know nothing about declarative or imperative designs. Many immediate mode GUIs output a vertex buffer or a list of draw commands that can then be rendered anyway you choose, including having it rendered by a GPU.

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

Can you give more details on how this GPU acceleration works?

Dear-imgui, the most popular and mature immediate mode GUI library, renders with OpenGL/Vulkan/DirectX.

Reply on news.ycombinator.com