Single buffering: You're drawing pixels directly on screen. Problem: Drawing isn't instant across whole screen, so human eye sees a blend of old and new image (and since screens draw top to bottom, this produces a horizontal "tear" somewhere, thus "screen tearing").

Double buffering: You're drawing pixels on a hidden screen while the previous image is displayed, then flip screens. This flip action is so fast it's practically instant, so tearing is solved. However, screens can only flip at set intervals (refresh rate). Problem: What if your drawing finishes even a little bit late, just after refresh rate sync? Now your program has to wait for the next opportunity to flip, which just makes everything hang.

Triple buffering: 3 is the magic number to fix all these problems. You always have two virtual screens to flip between, and a third one you can draw to regardless of flipping.

If the game renders on time, what you see on screen is always the latest completed image that was ready at previous vsync.

With two buffers, if you render too long and miss vsync and then call flip() which waits until the next vsync, you're wasting the frame waiting (because the system can only swap buffers at vsync, to prevent tearing).

The third buffer only exists so that the game can start working on the next frame, while two of the buffers are "locked" (one on screen, other ready for display, third available).

I worked on the netcode for EA games at one point in my life.

The highly popular battle royal and competitive shooters will never go cloud.

The majority of the people now think 24 frames a second looks natural and 60fps looks fake. They're twisted by their malevolent environment into a wrong and unnatural state, like elves into orcs.