XboxSeriesX
Member
In an ideal world, a developer would manage to bring in everything that it is necessary to calculate in the time on the screen to display each image, whatever is happening in the game. 60Hz means each image would be calculated in 16ms then sent to the screen, which would display it while the next image is calculated at the same time. The result would be a game running perfectly at 60 frames per second.
This is the challenge of “optimization”, so often criticized. But if the sacrosanct 60fps is not the priority of the developer, he can consider the no less optimized alternative of an image calculated every 2 screen refreshes, and take advantage of double the time, that is 32ms, to do more calculations. The result is a game running at 30 frames per second, with potentially more things on the screen, better AI, better physics but a less fluid image in motion, the display then repeating each image a time.
The main thing is that the source is synchronous with the display, that each image is sent at the start of the screen refresh, even every other time, but therefore at perfectly regular intervals.
FreeSync and VRR: The default to avoid-tearing
So what happens when this calculation time is not stable and ends in the middle of a screen refresh cycle? The source and the display are no longer synchronized. The source sends an image while the screen is scanning the previous one. When the image at the end of the calculation is not ready at the start of the screen refresh, it begins to scan the previous image again (remained in buffer memory, “framebuffer” in English, which controls the between the GPU and the screen), and finishes scanning with the information in the next image when it is sent. This results in a “tear” in the screen which displays both the top of the previous image and the bottom of the next image.
The main thing is that the source is synchronous with the display, that each image is sent at the start of the screen refresh, even every other time, but therefore at perfectly regular intervals.
FreeSync and VRR: The default to avoid-tearing
So what happens when this calculation time is not stable and ends in the middle of a screen refresh cycle? The source and the display are no longer synchronized. The source sends an image while the screen is scanning the previous one. When the image at the end of the calculation is not ready at the start of the screen refresh, it begins to scan the previous image again (remained in buffer memory, “framebuffer” in English, which controls the between the GPU and the screen), and finishes scanning with the information in the next image when it is sent. This results in a “tear” in the screen which displays both the top of the previous image and the bottom of the next image.
