Live data from Hacker News

A completely unoptimized terminal renderer that runs at several thousand FPS

twitter.com

1–10 of 21 posts

Re: A completely unoptimized terminal renderer that runs at several thousand FPS

#7
What does “thousands of frames per second” even mean when the monitor is displaying in the range of sixty frames per second or if you have a fast one, 144 FPS?

Is it just conceptual frames per second? So for the terminal to be doing 1,000s of frames per second then the graphics card is outputting thousands of frames per second?

I don’t get it. Where are these thousands of FPS?

Re: A completely unoptimized terminal renderer that runs at several thousand FPS

#8
post #7

What does “thousands of frames per second” even mean when the monitor is displaying in the range of sixty frames per second or if you have a fast one, 144 FPS? Is it just conceptual frames per second? So for the terminal to be doing 1,000s of frames per second then the graphics card is outputting thousands of frames per second? I don’t get it. Where are these thousands of FPS?

One frame, in this case, is the time it takes to do a full iteration of its loop containing all the input handling and rendering, up to and including the point where it flips its buffers for the main screen. Enabling v-sync would bring that down to your monitor's refresh rate, as it prevents the buffers from flipping until your monitor is refreshing.

Re: A completely unoptimized terminal renderer that runs at several thousand FPS

#9
post #8
post #7

What does “thousands of frames per second” even mean when the monitor is displaying in the range of sixty frames per second or if you have a fast one, 144 FPS? Is it just conceptual frames per second? So for the terminal to be doing 1,000s of frames per second then the graphics card is outputting thousands of frames per second? I don’t get it. Where are these thousands of FPS?

One frame, in this case, is the time it takes to do a full iteration of its loop containing all the input handling and rendering, up to and including the point where it flips its buffers for the main screen. Enabling v-sync would bring that down to your monitor's refresh rate, as it prevents the buffers from flipping until your monitor is refreshing.

So to be clear, there are no thousands of frames per seconds actually being displayed anywhere. There’s 144 at best.

The internal buffer is being updated thousands of times per second. The user will see their regular 60FPS.

Re: A completely unoptimized terminal renderer that runs at several thousand FPS

#10
post #9
post #8

Earlier quoted context omitted.

One frame, in this case, is the time it takes to do a full iteration of its loop containing all the input handling and rendering, up to and including the point where it flips its buffers for the main screen. Enabling v-sync would bring that down to your monitor's refresh rate, as it prevents the buffers from flipping until your monitor is refreshing.

So to be clear, there are no thousands of frames per seconds actually being displayed anywhere. There’s 144 at best. The internal buffer is being updated thousands of times per second. The user will see their regular 60FPS.

Where exactly is it claimed that it displays thousands of frames per seconds? The purpose is to show how fast the program is. This is standard practice in benchmarks. You show an FPS counter that doesn't correspond to the frames the monitor displays.
Post reply on HN