Godot or Unity? Why would you build a regular application GUI with that?

Those are for running a game or game like application constantly at XX fps, not for something that reacts to user input and should consume 0% cpu when it's not told to do anything.

Please tell me "modern" UI toolkits are still event driven and don't infinitely render everything in a loop like a game...

the thread you have (apparently unintentionally) posted this comment in is entitled 'ImRAD is a GUI builder for [an] ImGui library [for opengl]' :-)

more generally, guis that don't need to run constantly at xx fps don't have much reason to not be written in html5

Oh :(

I thought ImGui was a regular GUI library.

Why are people even mentioning VB6 and Delphi then in the comment threads?

Possibly because they made the same assumption that I made :)

imgui is a general approach to designing gui libraries proposed by casey muratori in 02005 https://www.youtube.com/watch?v=Z1qyvQsjK5Y; the particular library in question is omar cornut's 'dear imgui'

a gui that would use 100% of cpu on an 0.52-mips mac 512 https://netlib.org/performance/html/dhrystone.data.col0.html would probably use about 0.02% of cpu on one 2201-mips core of a raspberry pi 3 https://netlib.org/performance/html/dhrystone.data.col0.html

if you pessimistically multiply that by 32 to account for having 32 bits per pixel instead of 1, and by 12 to account for 1920×1080 instead of 512×342, it comes to 9%. of one of the cores! also it would run in 0.5% of the pi's ram

so, to a significant extent, the struggle is no longer to get something approximating your desired user interface running, but to imagine a user interface that's worth people's time to use. so it makes sense to trade off cpu consumption and ram usage for faster experimentation in a lot of cases

> it comes to 9%. of one of the cores! also it would run in 0.5% of the pi's ram

9% from one app, 9% from another, pretty soon we're talking about real power consumption / battery life

And even the 9% that you find trivial is something I, as an user, could use for something that gives me a benefit instead of your game-like GUI.

> so it makes sense to trade off cpu consumption and ram usage for faster experimentation in a lot of cases

It does not. If it has nothing animated, you'd better not redraw it. Anything else is lack of respect for the user's resources.

yes, you wouldn't be able to run more than about 450 such apps concurrently on the pi before they started to get slower. (if you were concerned about battery life, you wouldn't be using a pi; there are alternatives with orders of magnitude lower power usage, some of which can even run linux. but there's no way for a pi to use an amount of energy that's significant next to a human being, let alone a refrigerator or a car)

but 9% is really very pessimistic. 0.05% is a more realistic number

users are 100% entitled to spend their resources on whatever apps they think is worthwhile, and of course to spend their time programming their computers as inefficiently or efficiently as they want

> 450 such apps concurrently

this should read '45 such apps concurrently'

I recently saw a tweet where a programmer demanded that all UIs (and presumably their frameworks/toolkits) should be immediate mode.

So, yeah, there seems to be some desire for that kind of thing out in the wild these days.

react is immediate mode, and it doesn't have to refresh at xx fps; it only refreshes when a change in the data the gui is dependent on. (and the browser tends to refresh when there are input events)

This is the kind of thing that can easily devolve into a semantic argument. React presents an immediate mode like API but internally (both in the virtual DOM of React and within the actual DOM of the HTML document) the actual rendering path is very much retained mode.

The specific thread we are in isn't related to the benefits/drawbacks of API design but rather the performance implications of re-rendering the entire scene on every frame. As you mentioned, React doesn't re-render on every frame and therefore isn't really relevant to that discussion.

But render in the javascript library world means generating the html.

It has nothing to do with how the browser draws said html to the screen?

Rendering is a general term that can apply to many things. For example, in JavaScript there is `CanvasRenderingContext2D` [1] where "rendering" is about applying drawing commands to a canvas context.

So you are just proving my point that this kind of discussion devolves into a semantic argument. You want to define rendering one way. Someone else uses the term another way. It's the same problem with "immediate mode" vs "retained mode". People just throw the words around assuming that everyone uses them the same way.

In this way, no discussion is actually had. Just a bunch of people insisting that their personal definition of a term must be adhered to.

1. https://developer.mozilla.org/en-US/docs/Web/API/CanvasRende...

very plausibly the programmer you mentioned demanding that all uis be immediate mode was looking for the benefits/drawbacks of api design rather than the performance implications of re-rendering the entire scene on every frame; react shows one way they can be decoupled

They were talking about imgui, so no. Unless dear imgui is secretly an immediate mode API on top of a retained mode renderer?

Also, weren't you literally arguing in another thread that performance didn't matter? Some calculation about Raspberry Pis and percentages of cores? I'm starting to wonder how good faith of an argument is trying to be put forward here.

it seems like you're looking for an argument to win rather than new and exciting information to explore, and that's not what i'm here for. if i'm mistaken about something and i win the argument, what have i won? continuing to be mistaken?

in case you mislead other people, though, i want to point out that 'imgui' is often used to mean both 'immediate-mode guis' and 'dear imgui', which can be confusing