Tried it on Windows on a powerful workstation. Felt sluggish.
The framerate seems to be capped as 60Hz. My monitor is running at 240Hz.
Removing the framerate limit could help.
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.
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.
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.
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.
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.
> 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...
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.
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?
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
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.
Hey Ned developer here, there is a target fps slider in settings. I am able to get 800+fps on my MacBook m4. There is a mode where it reduces fps until user input on Mac to save battery life. However this only works with shaders turned off, as the shaders depend on continuous rendering.
Fifteen years ago I started to develop mild neurological symptoms. Mostly headaches, some minor muscle twitches, and some weird vision issues. I started working with first my GP and then with a neurologist to try to get to the bottom of it. The investigation was leading towards some form of optic neuropathy. In parallel I moved to a new job. All of my symptoms went away and in retrospect at the time all of the symptoms had started when I'd started that job. The fluorescent lighting near my desk there was terrible and as far as my doctors and I could figure out that was likely the cause of it.
Not the OP, but yeah that used to bother me when I was younger.
As did any CRTs running below 75hz
My “super power” used to be that I could tell what refresh rate a VDU was operating at just by looking at it. Well, I couldn’t tell past 80hz. But anything below that I could.
Most lights try to avoid flicker in the design, but bad/failing ones can drive one nuts. E.g. fluorescents flicker at 120 Hz (2 crossings per cycle) but the phosphor coating carries some glow and that they stay on for ~80% of the cycle time anyways makes it a lot more bearable that if it were an idealized instantaneous 50% duty at a 60 Hz rate.
So many "hackers" apparently did not hear about adaptive refresh. There is no need to update a static image every 240fps. You only need to increase the refresh rate for animations like scrolling, like in... everywhere??? Android, macOS, Chromium, Qt, and GTK(?) do this.
