That's not true. You can decide when to update the frame (e.g. an input event coming in). What is true is that usually the whole UI is repainted when a change does happen.
The author is absolutely wrong about ImGUI belonging to the gaming world. I have written a complete Unity-style editor using ImGUI and it was the best decision I ever made. I had to solve some issues such as layout and drag'n'drop with some custom code, but when this had been done, writing UIs and maintaining them became MUCH easier than more traditional widget-based approaches. You are liberated when you don't have to worry about lifetimes in a very dynamic environment.
Also, the author doesn't understand really what ImGUI is. It's sole purpose is to return vertex buffers and commands for the host to render. As a result, there is a lot of boilerplate to set that up. But ImGUI has many examples that implement a host using DirectX, OpenGL and others. You have to write it once and then you're done.
What specifically? Everything I've written is in the "Dear ImGUI" documentation, which you will mostly find in its source code. The part about writing an editor using Dear ImGUI is something I figured out myself at my job. I think Dear ImGUI has better support for layouts then it did when I wrote my editor, which was around 5 years ago. But you can see images of ImGUI efforts: twitter.com/proceduralguy/status/9...
That's not true. You can decide when to update the frame
Yes, you can. . But it isn't trivial. Here is my unfinished solution: github.com/0lru/p3ui (I think it'd require something like virtual dom in React to be lock-free and smooth). The thing I like about "ImGui" is its functional scope. Most of the provided frameworks here do not include performant plotting libraries like ImPlot. Although even ImPlot is not as performant as it could be. When looking into chrome and other GUI-related frameworks like React with its virtual dom, you begin to understand the problems and their solutions. In the end, it seems it's not only a rust-related problem. I don't know any framework that would make me fully satisfied, in any language, yet.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Immediate GUIs are repainted at each frame, meaning it's a waste of resources for desktop applications, as desktop GUIs don't update very often
That's not true. You can decide when to update the frame (e.g. an input event coming in). What is true is that usually the whole UI is repainted when a change does happen.
The author is absolutely wrong about ImGUI belonging to the gaming world. I have written a complete Unity-style editor using ImGUI and it was the best decision I ever made. I had to solve some issues such as layout and drag'n'drop with some custom code, but when this had been done, writing UIs and maintaining them became MUCH easier than more traditional widget-based approaches. You are liberated when you don't have to worry about lifetimes in a very dynamic environment.
Also, the author doesn't understand really what ImGUI is. It's sole purpose is to return vertex buffers and commands for the host to render. As a result, there is a lot of boilerplate to set that up. But ImGUI has many examples that implement a host using DirectX, OpenGL and others. You have to write it once and then you're done.
Do you have further reading to suggest about this ?
What specifically? Everything I've written is in the "Dear ImGUI" documentation, which you will mostly find in its source code. The part about writing an editor using Dear ImGUI is something I figured out myself at my job. I think Dear ImGUI has better support for layouts then it did when I wrote my editor, which was around 5 years ago. But you can see images of ImGUI efforts: twitter.com/proceduralguy/status/9...
Yes, you can. . But it isn't trivial. Here is my unfinished solution: github.com/0lru/p3ui (I think it'd require something like virtual dom in React to be lock-free and smooth). The thing I like about "ImGui" is its functional scope. Most of the provided frameworks here do not include performant plotting libraries like ImPlot. Although even ImPlot is not as performant as it could be. When looking into chrome and other GUI-related frameworks like React with its virtual dom, you begin to understand the problems and their solutions. In the end, it seems it's not only a rust-related problem. I don't know any framework that would make me fully satisfied, in any language, yet.