3 ms·

This is the exact opposite of what I want, actually: imgui keeps promising an official mode that doesn't totally melt the machine from running at peak refresh r

This is the exact opposite of what I want, actually: imgui keeps promising an official mode that doesn't totally melt the machine from running at peak refresh rate the entire time (since it was developed for games, not normal desktop apps), but it never materialises, and the hacks we all implement ourselves stop working as they update the code etc. Everyone seems to want 9234567345863489634589 fps, when that's IMO completely absurd for a normal desktop app, e.g. editor! What you actually want is low latency, not constant massive bandwidth and power usage. If all your normal desktop apps constantly ran at uncapped FPS, your computer would scream and laptops wouldn't last 5 minutes on battery.

64718283661 11mo ago
It should be running at 0 fps, then when there is movement it should run at refresh rate.
- pixelpoet 11mo ago
  It blows my mind how controversial this obvious point is; makes me wonder if people also keep their washing machines running at full tilt without any clothes in them.
gr4vityWall 11mo ago
Wouldn't it look stuttery if the user tried to drag windows or other widgets with a limited framerate? > What you actually want is low latency High frame rates directly contribute to lowering latency. I guess I'm the polar opposite of you here, I heavily prefer low latency/high refresh rates over low CPU/GPU usage, as long as the machine is plugged in to a power source.
- pixelpoet 11mo ago
  Maybe it's car analogy time: this is a bit like saying, well it's fine if my car is redlining 24/7, as long as it gets the speed I want when I happen to be on the highway. Nobody is saying they want to tolerate some horribly laggy interface for the sake of lower CPU usage. The point is simply about not wasting enormous amounts of power when it's not needed.
pdntspa 11mo ago
> This is the exact opposite of what I want, actually: imgui keeps promising an official mode that doesn't totally melt the machine from running at peak refresh rate the entire time I don't know what to tell you when you're fucking with an immediate mode UI library...
- pixelpoet 11mo ago
  So you're arguing that the definition of an IM UI library necessarily includes running at full screen refresh rate the entire time? Then how is it that many people, myself included, are able to hack fix this to only update when required? Why does the imgui dev himself promise official support for this?
  - mjburgess 11mo ago
    Retained mode (for desktop apps) was/is primarily about creating an object heirachy that allows you to minimize full redraws and the like --- you'd assume, for something immediate mode, that you're basically asking to push frames directly without any barriers
    - pixelpoet 11mo ago
      The most efficient way to answer the "no redraw needed" question is orthogonal to the "question" of whether or not to do redraws when not needed.
- gldrk 11mo ago
  Unless you are targeting Atari 2600, immediate mode still retains state in the form of a frame buffer. Your video game should not repaint if nothing has changed since last frame, e.g. when paused, let alone a text editor.
ocornut 11mo ago
I promise it’s coming eventually but I don’t believe the custom version is hard to make to work either.
- pixelpoet 11mo ago
  Oh wow, it's the man himself! I'm very sorry if I sounded ungrateful, imgui is the best damn thing to happen to UI coding ever <3 I will be so extremely happy when this lands, and imgui is already such a blessing.
stephc_int13 11mo ago
I would agree with that for desktop apps. Not refreshing unless needed. And this is not too difficult to do. But still, when other editors are refreshing at 240Hz, simply scrolling text or hovering over the file list seems sluggish at 60Hz.
torginus 11mo ago
And the worst thing is that with GPU rendering it's pretty easy to introduce extra latency - if you buffer too much, miss sync events etc - and there's inherently more latency to the rendering process than just writing a pixel color into a framebuffer and having it scanned out to the screen. The whole point of >60FPS would be to able to reduce the delay between the user action and the results appearing on the screen. The irony is just like with manufacturing and CPUs, the secret to getting high throughput necessary for high FPS is deep pipelining - meaning more delays compared to just drawing stuff. The parallel of this in games has been frame generation, and fake frames - the way this is implemented that the game waits an extra frame's worth of time, then starts generating an interpolated frame between the two states, which adds extra time as well. I propose, that instead of FPS, gaming benchmarks should move to the metric of action-to-pixel (ATP). For this metric, the FPS(or frame time) is a lower bound - if your game runs at 60FPS, your frames take 16.66ms to render - so by definition you can't react any faster than that. Not sure if anyone's working on this, but this would be a nice way to combat the framegen BS that's going on in the games industry right now.

64718283661 11mo ago

It should be running at 0 fps, then when there is movement it should run at refresh rate.

pixelpoet 11mo ago
It blows my mind how controversial this obvious point is; makes me wonder if people also keep their washing machines running at full tilt without any clothes in them.

gr4vityWall 11mo ago

Wouldn't it look stuttery if the user tried to drag windows or other widgets with a limited framerate? > What you actually want is low latency High frame rates directly contribute to lowering latency. I guess I'm the polar opposite of you here, I heavily prefer low latency/high refresh rates over low CPU/GPU usage, as long as the machine is plugged in to a power source.

pixelpoet 11mo ago
Maybe it's car analogy time: this is a bit like saying, well it's fine if my car is redlining 24/7, as long as it gets the speed I want when I happen to be on the highway. Nobody is saying they want to tolerate some horribly laggy interface for the sake of lower CPU usage. The point is simply about not wasting enormous amounts of power when it's not needed.

pdntspa 11mo ago

> This is the exact opposite of what I want, actually: imgui keeps promising an official mode that doesn't totally melt the machine from running at peak refresh rate the entire time I don't know what to tell you when you're fucking with an immediate mode UI library...

pixelpoet 11mo ago
So you're arguing that the definition of an IM UI library necessarily includes running at full screen refresh rate the entire time? Then how is it that many people, myself included, are able to hack fix this to only update when required? Why does the imgui dev himself promise official support for this?
- mjburgess 11mo ago
  Retained mode (for desktop apps) was/is primarily about creating an object heirachy that allows you to minimize full redraws and the like --- you'd assume, for something immediate mode, that you're basically asking to push frames directly without any barriers
  - pixelpoet 11mo ago
    The most efficient way to answer the "no redraw needed" question is orthogonal to the "question" of whether or not to do redraws when not needed.
gldrk 11mo ago
Unless you are targeting Atari 2600, immediate mode still retains state in the form of a frame buffer. Your video game should not repaint if nothing has changed since last frame, e.g. when paused, let alone a text editor.

ocornut 11mo ago

I promise it’s coming eventually but I don’t believe the custom version is hard to make to work either.

pixelpoet 11mo ago
Oh wow, it's the man himself! I'm very sorry if I sounded ungrateful, imgui is the best damn thing to happen to UI coding ever <3 I will be so extremely happy when this lands, and imgui is already such a blessing.

stephc_int13 11mo ago

I would agree with that for desktop apps. Not refreshing unless needed. And this is not too difficult to do. But still, when other editors are refreshing at 240Hz, simply scrolling text or hovering over the file list seems sluggish at 60Hz.

torginus 11mo ago

And the worst thing is that with GPU rendering it's pretty easy to introduce extra latency - if you buffer too much, miss sync events etc - and there's inherently more latency to the rendering process than just writing a pixel color into a framebuffer and having it scanned out to the screen. The whole point of >60FPS would be to able to reduce the delay between the user action and the results appearing on the screen. The irony is just like with manufacturing and CPUs, the secret to getting high throughput necessary for high FPS is deep pipelining - meaning more delays compared to just drawing stuff. The parallel of this in games has been frame generation, and fake frames - the way this is implemented that the game waits an extra frame's worth of time, then starts generating an interpolated frame between the two states, which adds extra time as well. I propose, that instead of FPS, gaming benchmarks should move to the metric of action-to-pixel (ATP). For this metric, the FPS(or frame time) is a lower bound - if your game runs at 60FPS, your frames take 16.66ms to render - so by definition you can't react any faster than that. Not sure if anyone's working on this, but this would be a nice way to combat the framegen BS that's going on in the games industry right now.