Vsync and Screen Tearing

A typical video tearing artifact (simulated image)
A typical video tearing artifact (simulated image)

Screen tearing is a visual artifact in video where information from two or more different frames is shown in a display device in a single screen draw. The artifact occurs when the video feed sent to the device isn’t in sync with the display’s refresh, be it due to non-matching refresh rates, or simply lack of sync between the two. During video motion, screen tearing creates a torn look as edges of objects (such as a wall or a tree) fail to line up. Tearing can occur with most common display technologies and video cards, and is most noticeable on situations where horizontally moving visuals are commonly found, such as in slow camera pans in a movie, or classic side-scrolling video games. The ways to prevent video tearing are dependent on the technology of the display device and video card, the software in use, and the nature of the material being shown. The most common solution is to use multiple buffering. Most systems will use this function along with one or both of these two methods:


Vertical synchronization is an option found in most systems, wherein the video card is prevented from doing anything visible to the display memory until after the monitor has finished its current refresh cycle. During the vertical blanking interval, the driver would order the video card to either rapidly copy the off-screen graphics area into the active display area (double buffering), or treat both memory areas as display-able, and simply switch back and forth between them (page flipping).


When vertical synchronization is in use, the frame rate of the rendering engine will exactly equal the monitor’s refresh rate, if it was higher. Although this feature normally results in improved video quality, it is not without trade-offs in some cases.


Vertical synchronization can also lead to artifacts in video and movie presentations, as they are generally recorded at frame rates significantly lower than the typical monitor frame rates (24–30 frame/s). When such a movie is played on a monitor set for a typical 60 Hz refresh rate, the video player will miss the monitor’s deadline fairly frequently, in addition to the interceding frames being displayed at a slightly higher rate than they were intended for, resulting in an effect similar to judder – see Telecine: Frame rate differences.

Input lag

Video games, which have a wide variety of rendering engines, tend to benefit well visually from vertical synchronization, as a rendering engine is normally expected to build each frame in real time, based on whatever the engine’s variables specify at the moment a frame is requested. However, because vertical synchronization causes input lag, it interferes with the interactive nature of games, and particularly interferes with games which require precise timing or fast reaction times.


Lastly, when one wishes to benchmark a video card or rendering engine, it is generally implied that the hardware and software render the display as fast as possible, without regard to monitor’s capabilities or the resultant video tearing. Otherwise, the monitor and video card will throttle the benchmarking program, causing it to generate invalid results.

Many games have internal limits that prevent them rendering faster than a certain frame rate. In some cases this can mean they are locked at a maximum frame rate of only 20 fps. The maximum frame rate you can obtain is equal to the refresh rate of your display.

When you have Vsync enabled: Vsync is used to synchronize the output of your graphics card with the display of your monitor. When your graphics card has finished rendering the next frame it waits for the monitor to finish displaying the current one before switching to the new one. This means that the maximum frame rate you can obtain will be equal to the refresh rate of your monitor (which is usually 60 Hz, 75 Hz, 85 Hz, or  100 Hz).

If you disable Vsync, then your graphics card will continuously render without waiting for the last frame to be displayed in its entirety. With fast graphics cards this means that your monitor may switch to a new frame halfway down the screen. This effect is known as tearing as there appears to be a visible line separating two different halves. Due to this, you should generally leave Vsync enabled except when benchmarking.

Resources used: wikipedia

Automated Tweaking and Tuning Tool for FSX

This resource is no longer available

highmemfixWith this link you get a tweaking tool for FSX SP2 en FSX Acceleration.

The tool works as follows:
after filling the values of number of threads, speed of your CPU, type of graphics card and optimization preference, you will be asked to send the config file: fsx.cfg.
With Step 1 it will open the file, so skip this step! and continue with Step 2 and browse with the BROWSE button to:
Then press: Click here to begin.
A copy of the file is sent and analyzed.
After the analyzing you get a choice to upload a modified fsc.cfg. In this new file the tweaks are present.

results-fpsThese are the results for my personal fsx.cfg, which I downloaded and replaced with the generic one. (Rename the existing original fsx.cfg into fsx_old.cfg)


Under the hood…

HIGHMEMFIX (is not valid vor FSX-SE)
Enables the D3DXFX_LARGEADDRESSAWARE flag to be passed to all the Shader Compile functions in FSX (eg. D3DXCreateEffect, D3DXCreateEffectFromFile etc.) so that when FSX uses more than 2GB of memory, the D3DX Effects system ALSO is permitted to use this upper memory space. Without HIGHMEMFIX FSX will crash when switching views, alt-tabbing or simply textures will get corrupted after a long flight and if using resource hungry add-ons. This was a ‘BUG’ MS simply forgot to enable HIGHMEMFIX by default. ESP/Prepar3D has this enabled by DEFAULT.

Will ‘cap’ the amount of data that is sent per-frame to the Dynamic Vertex Buffers. Originally, FSX had this value set to 2MB, a big NO NO for Dynamic Index and Vertex buffers. When using Dynamic buffers the most efficient way to increase performance is to send ONLY the amount of data streamed to the card per single frame, usually this is 128-500 KB. The UsePools=0 option will also make performance better, because the Dynamic vertex buffers are bypassed, however, this creates a problem because of the way FSX is programmed (Lock/Unlock of Dynamic Vertex Buffers). Having UsePools=0 means that the CPU can stall the GPU with requests (they go directly into the card’s command buffer) and not the Index/Vertex buffers so FSX has no way to control the ‘flow’ of data. This two options behave differently depending on your hardware. For example, if you have a VERY fast card, then having Dynamic buffers (RejectThreshold) with a small value will yield the absolute best performance. In your card is not fast enough, then you are better off with UsePools=0. All newer cards (eg GTX400 series), MUST use RejectThreshold instead of UsePools=0. The performance improvement for this change is remarkable.

vSync FIX
FSX included two options to enable vSync, but they were deprecated, not used anymore. ‘real’ switches to enable vsync in FSX were discovered in April 2010 by a dedicated FSX user (that would be me). Enabling vSync eliminates ‘tearing’ but also reduces your FPS in half (to 30) due to the inability to keep 60 FPS constant. If 30 can not be kept, then FSX will fall to 20, then 15, 12 and so on.. that’s why it is SO important to lock your frames EXTERNALLY to either 30 or 20.. you have to use multiples of 60 for optimal results. You also have the option to disable vSync completely by unchecking the corresponding option when providing information about your configuration in the previous page.

[GRAPHICS] TextureMaxLoad
Affects the ‘throttling’ algorithm FSX uses when pumping textures per-frame. This value, defaults to 3, which is extremely LOW, current hardware is more than happy with this value set to 30, SPECIALLY when running frames UNLIMITED and locking your frames externally.

SWAP_WAIT_TIMEOUT For maximum benefit, this setting requires a HIGH TextureMaxLoad value, with a low SWAP_WAIT_TIMEOUT setting (such as 2) you are telling the terrain engine in FSX that in should only wait ’2′ frames, before looking for terrain tiles in Video Memory. The loading speed of terrain textures is affected by TextureMaxLoad

Unlimited frames / External Frame locking: It might sound ‘confusing’ to ask you to set FSX to unlimited frames and at the same time ask you to LIMIT them externally. The reason, is because FSX is ‘optimized’ to process terrain loading on your additional CPU’s but ONLY when frames are set to unlimited. Unfortunately, running frames to unlimited also stresses FSX unnecessarily, so to counter this you need a very simple app that limits your FPS so CPU/GPU usage within FSX is kept constant to reduce stuttering due to CPU spikes. The tool can be downloaded here you need WinRAR (a program similar to WinZip) in order to open the file. You’ll notice that FPS fluctuates a bit when using the FPS limiter, don’t worry this is completely normal, most of the time it will maintain FPS constant which is what you need.

AffinityMask is determined automatically based on your current hardware configuration so it uses only 3 cores (Main scheduler and two texture managers) leaving core 0 free for fibers which handle terrain loading.