4 ms·

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 so

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

kragen 2y ago
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
- nottorp 2y ago
  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 :)
  - kragen 2y ago
    imgui is a general approach to designing gui libraries proposed by casey muratori in 02005 https://www.youtube.com/watch?v=Z1qyvQsjK5Y 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 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 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
    - nottorp 2y ago
      > 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.
      - kragen 2y ago
        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
        kragen 2y ago
        > 450 such apps concurrently this should read '45 such apps concurrently'
zoogeny 2y ago
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.
- kragen 2y ago
  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)
  - zoogeny 2y ago
    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.
    - kragen 2y ago
      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
      - zoogeny 2y ago
        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.

kragen 2y ago

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

nottorp 2y ago
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 :)
- kragen 2y ago
  imgui is a general approach to designing gui libraries proposed by casey muratori in 02005 https://www.youtube.com/watch?v=Z1qyvQsjK5Y 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 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 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
  - nottorp 2y ago
    > 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.
    - kragen 2y ago
      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
      - kragen 2y ago
        > 450 such apps concurrently this should read '45 such apps concurrently'

zoogeny 2y ago

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.

kragen 2y ago
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)
- zoogeny 2y ago
  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.
  - kragen 2y ago
    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
    - zoogeny 2y ago
      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.