What is V-sync and what is tearing?
V-sync (vertical sync) is a function of the windows system or graphics driver on your computer which RV uses. When RV is finished rendering a frame, it waits to show it until the display device is finished showing you the current frame. This ensures that you never see a frame being updated while the device is in the process of showing it to you. When that happens it’s called tearing because the symptom is a horizontal line above which you see a different frame than below the line. Sometimes the horizontal tearing line will move up or down over time, other times it will remain in the same part of the frame.
V-sync options in RV
In RV’s rendering preferences, there is a option called Video Sync. Depending on the platform, this option can be used to enable/disable V-sync. On OS X and Windows the default behavior is V-sync on. On these platforms you can disable the system V-sync using RV’s preferences.
On Linux things are much more complex. With NVIDIA drivers on Linux there are two completely different OpenGL V-sync methods: one at the driver level and another controlled by RV. In addition, the nvidia driver recognizes a number of environment variables which can control how V-sync operates, especially when multiple monitors are attached to the GPU.
Different versions of RV
RV’s internal rendering changed in version 3.12.12 to make it more "modern". On OS X and Windows no visible changes should be seen other than the fact that RV should be "faster" playing back some media; this is especially the case in presentation mode. However, on Linux, depending on the driver version, V-sync may behave differently in 3.12.12 and newer RVs.
Timing issues that affect all platforms
The most difficult issue to understand is related to the physical characteristics of the monitor/projector and the frame rate of the media being played on that device.
When playing 24 frames/second (24Hz) media on a monitor with a refresh rate of 60Hz (60 frames per second) you can only emulate the timing of frames being played on a 24Hz movie projector. It’s not possible to literally get the same timing. The reason is simple math: you can’t evenly divide 60 by 24.
RV tries to get around this issue by playing back at as close to the device rate as possible (in this case 60Hz) and by trying to spread out 24 frames over the 60 actual frames in a visually pleasing way. If you were to look at the timing of the frames you would see that some frames are played back 3 times in a row and others only 2.
The only way around this problem is to match the output device rate to the media rate in such a way that the device rate is evenly divisible by the media rate.
V-Sync on Linux with NVIDIA drivers
NVIDIA drivers on Linux have a number of V-sync options:
- The driver’s OpenGL V-sync available in the nvidia-settings control panel (ignore the similarly named XVideo V-sync)
- RV’s V-sync available from its rendering preferences
- The __GL_SYNC_TO_VBLANK environment variable
- The __GL_SYNC_DISPLAY_DEVICE environment variable
Regrettably, all of these options can interact with each other. We recommend that you use the following setup:
- The driver’s OpenGL V-sync is ON
- RV’s V-sync is OFF
- Do not set __GL_SYNC_TO_VBLANK
- If you have 2 or more monitors attached to the GPU set __GL_SYNC_DISPLAY_DEVICE to indicate which monitor you want to sync to. Once RV starts, the driver cannot change the sync device so you should choose which one you want explicitly. Otherwise the driver decides on one itself (usually the "main" monitor). Set the env var to the name the driver uses for the monitor like DFP-1, CRT-1, etc.
Look at any output in the shell RV was started from for diagnostic messages about V-sync. RV tries to detect configurations that will result in tearing. If it detects a bad configuration it will inform you in the shell (or console window). In presentation mode RV will pop up a dialog box warning of impending tearing if can detect it.
Under no circumstances should you set both the driver V-sync and RV’s at the same time.
General Linux issues
On Linux it’s possible to tune the kernel to various tasks. When doing a lot of heavy computation it’s often the case that you want longer time slices for each process. Unfortunately, this is bad for RV. RV works best when it gets a lot of smaller time slices. If your kernel is set for long time slices it can result in bad playback stability. One way around that is to use RV’s realtime scheduling as described in Streaming Playback.