V-Sync (How Software Works)

How Software Works is a book and video series explaining the magic behind software encryption, CGI, video game graphics, and a lot more. The book uses plain language and lots of diagrams, so no technical or programming background is required. Come discover what's really happening inside your computer!
This episode is about V-Sync, or vertical synchronization, which is a gateway to talking about problems with the mismatch between how fast a program produces images, and how fast a screen displays them.
Learn more about the book...
- At the Amazon page (amzn.to/1mZ276M).
- At my publisher (www.nostarch.co...)
- At my site (www.vantonsprau....
If you'd like to contact me visit my site (vantonspraul.com), or just leave a comment below. Suggestions for future topics are welcome!

[@driftnate853]

Great videos! Came from a dijkstra video you did and I'm very happy to have come across your channel! Keep up the good work!

[@eduardopetry911]

Your videos are top notch, sir. It'd be great if you could make some more videos on software-related concepts/solutions! Thanks a lot for this.

[@vantonspraul]

Thank you! I hope to have some more how-software-works videos up soon.

[@hyp3rzen829]

Incredibly informative and easily understandable video, I really enjoyed it! The visual representation of the buffers is sooo helpful!
However, I am wondering about one thing. Assuming the GPU just so happens to produce new frames at around 60 fps, without any framerate control - then what are the chances that the buffers will switch in the middle of a refresh?
Or, an analogous question would be - how long does one refresh take? (Or, in terms of the visual representation in the video - how long does it take for the green line to go from the top of the blue rectangle to the bottom?)
Because if it takes e.g. 1/120 of a second, then any frame displayed on the monitor will have about 50% chance of having tearing. If it takes 1/180 of a second, the chance will be 33% - am I understanding it correctly?

[@vantonspraul]

Glad you enjoyed the video!
That's a good question. Back with old cathode ray tube displays, the analog control of the raster beam couldn't get the bream from the bottom left of the screen to the top instantly, so there was a delay between the end of one frame and the start of another. So there would be a decent chance of switching when it wouldn't be seen. Thing was, back then double buffering wasn't commonly used, and instead, the code was written to do all the updates to the screen buffer during that delay (known as the vertical blank, because on television signals, that part of the signal would be blank to turn the beam off while it returned to the top).
On a modern digital monitor, I don't know if there's a significant delay between refreshes; since there's no technical reason there needs to be, it would only happen if the screen is simply able to refresh much faster than needed to maintain the specified rate, at which point you might simply be able to set the screen to a faster rate. But I don't know for sure.

[@hyp3rzen829]

@@vantonspraul Thanks for the reply! So that's interesting - basically this means that if the GPU outputs roughly the same fps as the monitor's refresh rate, without any framerate control, then pretty much every frame is going to have some tearing... That's kinda counter-intuitive because I never use Vsync in my games and I've never noticed any significant tearing... Maybe I'm just one of those people who don't notice it ¯\_(ツ)_/¯

[@startupyahia1456]

Thanks

[@charanguggulla6899]

thanks.please make more videos on this topic

[@vantonspraul]

More on v-sync specifically, or more on graphics in games? I've thought about making a video on anti-aliasing.

[@charanguggulla6899]

More on how software works

[@ankk98]

Make videos on how operating systems work