Troubleshooting performance issues

Troubleshooting performance issues will help you if:

• you think that FlightGear could run smoother on your computer
• your hardware is not exactly from the latest generation
• you're already fiddling with the settings but can't get any FPS out of it
• you're trying to track down who's responsible for graphics artifacts you're seeing.

By progressively following all the hints of this page, in fact, you'll slowly get to a minimum startup profile in which most properly configured machines should have no problems.

Performance in FlightGear

What can I aim at?

It depends on many things as you'll see. It's easier to tell you what you should aim at: at least 20 FPS (frames per second). Under this value, things get very choppy and especially flying VFR will be more difficult. A much more decent value is 30 FPS, also to face better possible stuttering.

It makes no sense to exceed the refresh rate of your monitor. This is typically 60 FPS, but some monitors support speeds as high as 120 FPS.

How do I see my framerate?

During the simulation, open the View > View Options menu and toggle Show frame rate. You'll see the number at the bottom right of the screen.

How do I use this page?

Below, you'll find a list of performance factors. Each of them affect performance, but it's not the same for everyone. So, to find out what you can give up for less stuttering, more regular FPS, or what's killing the framerate, or what could be causing certain artifacts, you'll have to check each of them.

Most important, you'll have to check them singularly, otherwise you'll never be sure if one of the factors is more determinant than others. Also, make your experiments in a fixed environment, like always starting with the same aircraft on the same runway.

The list order is reasoned, so try to follow it, unless you know what you're doing (e.g. everything worked, until you have fiddled with some particular options and broke it.) We know it's boring, but this is the only way to try to fix these issues.

Minimal startup profile as a faster alternative

If you feel like fiddling with configuration files, command line options and such, you can ease the process and make it more thorough by using the minimal startup profile that is used for troubleshooting crashes. The idea is always the same: change options one at a time (you can do that also in-sim) and tune them to suit your needs.

Performance factors

Hardware setup

• Problematic video cards: There is a list of Problematic Video Cards. Check that yours is not there.
• Integrated video cards: These are probably in the above list, but sometimes you can play with them, reducing "eye candy". Two of these cards are Intel HD graphics 3000 and 4000. With integrated video cards it's also often possible to specify the amount of system memory to be shared and used as video RAM (VRAM).
• Video screen: Actually, this does not affect performance. The problem though is that with a large screen you might want to use higher resolution, but that will affect performance (and so will color-depth).

Operating system and driver setup

• Background programs: Check that your operating system is not cluttered by unnecessary programs running in the background. Have as little programs running as possible.
• Maximize power performance settings: If you're running a laptop, chances are your system defaults to a power-saving mode, even with the laptop plugged in. Adjust these settings to maximal power while running FlightGear.
• Disable Optimus/Hybrid Graphics: Most notebooks that run Windows 7 have the so called Optimus Technology (NVidia) or Hybrid Graphics technology (ATI) onboard. This is meant to increase battery life, by automatically switching of the powerful graphics card when it's not needed. However, FlightGear needs it all the time, even if Optimus says it doesn't! This miscommunication results in low framerates (because your computer will run Flightgear on the weak onboard processor) and often FlightGear will quit with the following error:

Unknown exception in the main loop. Aborting... 
Possible cause: Not enough space

If you own an NVidia card, check that it is actually used:

1. Go to the NVidia control panel. Probably located in the Windows Control Panel.
2. Open the 3D Settings tab. Now there's two options you can take:
   • On the "General settings tab", set "Prefered graphics processor" to NVidia. The NVidia card will now be used for all software. This can decrease battery life significantly.
   • On the "Programm settings" tab, locate fgfs.exe (eg. C:/Program Files/FlightGear/bin/win32/fgfs.exe) and assign the NVidia card to it. From now on the NVidia card will be used for FlightGear.

• Linux users: Many newer Linux distributions come with 3D enhanced, composite desktop environments (KDE4, Compiz, Fusion...) They're known to consume CPU and GPU resources, even slowing FlightGear down by 10 FPS. Choosing another window manager from the login screen, like XFCE, results in higher FlightGear performance. Setting "Compositing" to "off" in KDE4 might also help.

Graphics drivers setup

• Graphics card drivers: Ensure that the manufacturer's graphics card drivers are installed. You may be able to download and install drivers specific to your card from the manufacturer's site. See Graphics drivers configuration.
• Graphics drivers settings: Disable Anti-Aliasing and Anisotropic Filtering or at least set them to their lowest settings. Decreasing the setting for Mip-Mapping to its lowest setting can also help.

FlightGear configuration

From FlightGear Launcher (some options appear also during the simulation, so better to check them there too):

• Rembrandt: If you enabled the Rembrandt renderer, well, you knew that's experimental. First of all, try to change shadows settings, and consider disabling them. If it's not enough, disable Rembrandt altogether. To check if it's enabled: last tab, Advanced > Rendering > uncheck Rembrandt.
• 3D Clouds: One of the worst offenders in terms of performance impact. Disable them. (in-sim too)
• Screen resolution: The amount of pixels that the graphics card must draw affects performance, so reducing resolution can often help.
• Shading: Set to "flat"
• Fog: set to "nicest" or "disabled"
• Visibility: Try reducing visibility, especially with high-detail scenery. (corresponds to bare settings in-sim, View > LOD settings)
• Log level: Check that the log level is set to "alert" in Advanced > Debugging > Log level. Logging can cost some FPS.
• Everything else: Both Advanced > features and Advanced > rendering have few settings that you can try out.
• Texture compression: If you're experiencing stuttering when turning left/right or when loading new tiles, it is possible that texture compression is not handled correctly. Disable it by adding the property /sim/rendering/texture-compression=off in FGrun: Advanced > Properties. This can be tried for nVidia, ATI cards and for Intel integrated chips with MesaGL, that suffer from bugs with texture compression and FlightGear.
• Multithreading: WARNING! If you know what you're doing, in defaults.xml enable <multithreading-mode>. If your framerate is lower with this setting enabled, and both you and your computer survived, disable it again.

During the simulation:

• Shaders: If you cranked all the way up these settings, it's very likely the cause of your FPS problem, and possibly of any artifact. To check, during the simulation go in View > Rendering options, check the Shaders slider position. If that seems the problem, you can select Custom and try to see which one, at which position is the cause of your problems. It can be a particular combination of them, too.
• Random features: Try disabling, one by one, random buildings, random objects, random trees. If any of them seem to be the cause of your problems, you could try to fine-tune their density, or just leave them disabled. They require to reload the scenery.
• Everything else: Try disabling one by one each of the other rendering features. Some will need a restart.
• Framerate limiter: be sure that it's unchecked, or that it's not forcing to a too low FPS.

FlightGear simulation choices

• Time of day: Changing from nighttime to daytime flying is not only easier on the piloting, but also easier on the graphic requirement. Check the "Time of day" box and select a daytime setting. This is not true, however, if you have shadows enabled: these are pretty consuming, and present only during daytime.
• Location: KSFO is a wonderful airport but also known for a high-volume of traffic, which can slow performance. Try another airport if you encounter performance issues.
• Rural flying: While framerate may initially be as slow as 5 fps during takeoff, they may jump 5x or more after flying out to less-populated areas.
• Weather: Fly in clear skies. Clouds always incur a more or less pronounced performance hit.
• Choice of aircraft: Certain aircraft have lower resource requirements, especially the UFO. The 777 instead is known to be quite heavy.
• 2D panels: Although 3D cockpits look very tempting, simple 2D panels are much easier on the framerate.
• AI traffic: AI Traffic is computer controlled traffic, which includes traffic over the Multiplayer network. By turning off this function you're not able to see other aircraft. Most stuttering, or lag, is caused by the need to load the models for these aircraft while they appear. It can range from a minor annoyance to a crash. Turning off just the computer-generated aircraft (leaving the MP traffic visible), can be done by adding the property /sim/traffic-manager/enabled=0 to FGRun, through Advanced > Properties.

Nothing worked. Now what?

It is unlikely, so this must be more than a simple performance issue. You'll need to ask for someone's support and provide them some diagnostic data. See Troubleshooting graphics artifacts for information on how to do that.

For the geeks out there

FPS and frame spacing

Frames per second is an average by definition, and as such is not an optimal indicator of performance, because you could have half a second with 100 FPS and the other half with 0 FPS. You'd get a respectable 50 FPS but an unacceptable stutter of 0.5 seconds. A much better one is keeping track of the maximum frame spacing (i.e. the delay/time needed to create new frames), that gives a measure in milliseconds of the worst performance during a fixed interval.

Tools for performance evaluation

The performance impact can be evaluated by using:

• The frame rate counter (frames created per second)
• The frame spacing indicator (latencies between rendered frames)
• The built-in system monitor (can be inspected via telnet/http using --telnet=5900)
• The OSG on-screen stats
• The Built-in Profiler
• Testing your OpenGL performance

Some more details on the inner workings

FPS throttling

Older versions of FG (before 1.9) would get choppy if the frame rate got too high (well above the monitor refresh rate) but newer versions seem to have less problems with this. However, depending on your system setup you may need to throttle the frame rate to prevent choppiness at high frame rates, but it's not very likely with the current version of FlightGear. Most users anyway don't have enough GPU power to be concerned about frame rates getting too high with current FlightGear versions and those (lucky) users can, to some extent, throttle frame rates by increasing/maximizing eye candy settings.

How FPS affects the simulation

Keep in mind that things like nasal listeners, animations and other parts of the sim run at the video frame (main loop) rate and if your frame rate gets too low these things might not work as well as they should. As an example, if your aircraft is one armed with machine guns, you may see the guns change rate of fire if your frame rate is too low. This will definitely be the case with the JSBSim P-51D if your frame rates are below 30fps. As more things are decoupled from the main loop this should become less of an issue in future versions of FlightGear.

Additionally, the more the framerate decreases, the more other features of the simulation will suffer. The current FlightGear software architecture is such that long rendering times (slow framerates) may prevent other parts of the flight simulator, such as the autopilot, from having sufficient CPU time to respond correctly in the context of the simulation.

More on factors

FlightGear's framerate is influenced by various factors, including:

• scenery complexity (terrain, clouds, trees, particles, random 3D objects, multiplayer/AI traffic, animated jetways)
• cockpit complexity (2D vs. 3D)
• environmental options (eg. visibility, precipitation)
• FDM update interval
• AI scenarios
• aircraft speed (scenery paging)
• rendering options
• debugging level

A note from the developers

Performance and the OpenGL Shading Language (GLSL)

If working through this article doesn't solve the problem, you are probably facing a hardware/driver issue, which means that you may need to fix your drivers (version or settings).

If however at some point the error stops from occurring, that would suggest that FG is using some "code paths" that are not supported by your current driver. We have an increasing number of GLSL shaders, while most of the existing FG code was really only written with a fixed rendering pipeline in mind - and in fact, much of it even predates the OSG port, such as for example the GUI (PLIB/PUI).

In summary, our way of using OSG is not particularly optimized, and we're doing a lot of things that are known to be inefficient, such as having lots of GL state changes, and using legacy GL code in conjunction with more modern code. All of these also affecting compatibility, because GLSL, unlike DirectX shader code, is not bytecode, but compiled on-the-fly by your driver - in other words, each GPU vendor will typically have their own GLSL compiler implementation, and these are known to be fragile under certain circumstances. We do not have the resources to test each shader on all major hardware platforms, so we really rely on end-user quality feedback, e.g. by using tools like gDebugger or the corresponding ATI/AMD and nvidia equivalents.

The move to OpenSceneGraph (OSG)

Some people have been suggesting to our core/shaders developers to switch to AMD/ATI or even Intel hardware in order to get rid of certain problems. But it's not as simple as that to be honest: FlightGear is a fairly old code base, and it also isn't particularly modern - these days, many parts are basically unmaintained, and haven't been touched in years, despite containing lots of legacy code.

OSG is much more powerful than you may think, but it cannot magically fix all the problems that FlightGear introduces, we have a ton of features that basically still date back to the pre-OSG days, i.e. when we were using purely PLIB and SDL. OSG itself is generally rock-solid and there are rarely any issues found with it. To see for yourself, just run fgviewer or any of the OSG examples (osgviewer).

As recently pointed out elsewhere, those OSG examples even support Intel GMA cards, often even shaders to some degree - but we have never really formalized the way OpenGL/OSG code is written/developed for FlightGear, including effects and shaders.