A very small utility I wrote to test variable refresh rate on Linux. Should work on all major OSes.
Just run the executable. Builds are provided for Windows and Linux (64-bit). You can download the LÖVE [https://love2d.org] runtime to run the .love file on any supported OS on any supported architecture.
Assuming the runtime is installed and in PATH, you can run it with love <dir>, where <dir> is the directory where this repo is cloned/extracted.
Ctrl+f toggles fullscreen.b toggles busy waiting. Having it on makes the framerate more precise, at the cost of a ton of battery and CPU utilization. Off by default.s toggles VSync.f toggles fluctuating framerate; Ctrl+↑/↓ changes the maximum framerate, Ctrl+←/→ changes the fluctuation speed.r toggles random stutter; Alt+↑/↓ changes the amount of stuttering. Hold Shift as well to change faster.Alt+←/→ changes the monitor the tool will be displayed on.l increases the amount of information shown on the screen, from nothing, to GPU-related information, to a list of frametimes. Wraps around.As of version 2.0.0, VRRTest supports different scenes, of which there are currently two. (A 100% increase over previous versions!)
The first and default scene, Bars, is easy on the eyes (I'm not claiming it looks good; you'll see what I mean in the screenshots section) and easily allows the user to detect screen tearing, by displaying vertical bars moving towards the right. The number and speed of said bars are tunable by the user. Additional controls are as follows:
+ and - will change the amount of columns.The second scene, Squares, adopts a higher-contrast color scheme (pure white on pure black) due to one of its functions. It displays a grid of squares, lighting up one (or more; see further) square per frame, each frame switching to the next one. The size of the squares can be changed by the user. Optionally, a trail can be set to light up more than one square per frame (or to have squares stay lit up for more than one frame; the end result is the same) to achieve two different functions:
Additional controls are as follows:
+ and - will increase or decrease, respectively, the size of the squares.Some of these can't be screenshots. I apologize in advance for the quality of the pictures I took, as I don't own a camera or a tripod, both of which would prove useful in taking long-exposure pictures.
How the Bars scene is supposed to look like, without any screen tearing. Ignore the visible portion of the cursor, please.
A screenshot of how the scene looks like with screen tearing.
How a still frame of the Squares scene looks like. Its usefulness can't easily be conveyed by still screenshots.
Long-exposure picture of a monitor with Freesync disabled with lower framerate than its refresh frequency. Notice how some squares are brighter than others, caused by duplicated frames.
Long-exposure picture of a monitor with Freesync disabled with higher framerate than its refresh frequency. The empty squared are caused by dropped frames. Note that this might happen on a Freesync monitor too, when above its frequency range.
Finally, a long-exposure picture of a Freesync monitor with refresh rate within its range. Everything looks like it should, with every lit square being approximately the same as the others.
Long-exposure picture of a Freesync monitor with higher framerate than its maximum refresh frequency. VRR can't do much in this case; either limit your framerate to below your monitor maximum refresh frequency or enable V-Sync in your software and/or driver.
Hacker News (1)
Lua
96.0%
Makefile
4.0%
A very small utility I wrote to test variable refresh rate on Linux. Should work on all major OSes.
Just run the executable. Builds are provided for Windows and Linux (64-bit). You can download the LÖVE [https://love2d.org] runtime to run the .love file on any supported OS on any supported architecture.
Assuming the runtime is installed and in PATH, you can run it with love <dir>, where <dir> is the directory where this repo is cloned/extracted.
Ctrl+f toggles fullscreen.b toggles busy waiting. Having it on makes the framerate more precise, at the cost of a ton of battery and CPU utilization. Off by default.s toggles VSync.f toggles fluctuating framerate; Ctrl+↑/↓ changes the maximum framerate, Ctrl+←/→ changes the fluctuation speed.r toggles random stutter; Alt+↑/↓ changes the amount of stuttering. Hold Shift as well to change faster.Alt+←/→ changes the monitor the tool will be displayed on.l increases the amount of information shown on the screen, from nothing, to GPU-related information, to a list of frametimes. Wraps around.As of version 2.0.0, VRRTest supports different scenes, of which there are currently two. (A 100% increase over previous versions!)
The first and default scene, Bars, is easy on the eyes (I'm not claiming it looks good; you'll see what I mean in the screenshots section) and easily allows the user to detect screen tearing, by displaying vertical bars moving towards the right. The number and speed of said bars are tunable by the user. Additional controls are as follows:
+ and - will change the amount of columns.The second scene, Squares, adopts a higher-contrast color scheme (pure white on pure black) due to one of its functions. It displays a grid of squares, lighting up one (or more; see further) square per frame, each frame switching to the next one. The size of the squares can be changed by the user. Optionally, a trail can be set to light up more than one square per frame (or to have squares stay lit up for more than one frame; the end result is the same) to achieve two different functions:
Additional controls are as follows:
+ and - will increase or decrease, respectively, the size of the squares.Some of these can't be screenshots. I apologize in advance for the quality of the pictures I took, as I don't own a camera or a tripod, both of which would prove useful in taking long-exposure pictures.
How the Bars scene is supposed to look like, without any screen tearing. Ignore the visible portion of the cursor, please.
A screenshot of how the scene looks like with screen tearing.
How a still frame of the Squares scene looks like. Its usefulness can't easily be conveyed by still screenshots.
Long-exposure picture of a monitor with Freesync disabled with lower framerate than its refresh frequency. Notice how some squares are brighter than others, caused by duplicated frames.
Long-exposure picture of a monitor with Freesync disabled with higher framerate than its refresh frequency. The empty squared are caused by dropped frames. Note that this might happen on a Freesync monitor too, when above its frequency range.
Finally, a long-exposure picture of a Freesync monitor with refresh rate within its range. Everything looks like it should, with every lit square being approximately the same as the others.
Long-exposure picture of a Freesync monitor with higher framerate than its maximum refresh frequency. VRR can't do much in this case; either limit your framerate to below your monitor maximum refresh frequency or enable V-Sync in your software and/or driver.
Hacker News (1)
Lua
96.0%
Makefile
4.0%