In Italy we say "Do as shrimp"... ;)

[abassign]

In Italy we say "Do as shrimp": do a step forward followed by two steps backwards!

I have a PC with linux Kubuntu 16 GB, 6 GB NVIDIA 870. Until 10 days ago, FGFs 3.3 was good enough, on average 25-35 fps with the F14B and Rembrandt. Then, suddenly the speed dropped to 3-5 fps! I looked in the forums and find out that others have encountered the same problem. For now, I compile each day from GIT, I have not seen any improvement, in fact, a couple of days in the version without Rembrandt, some types of trees have become rectangles! Better and better!
The slow implementation of the program is actually with Rembrandt, but also without Rembrandt. I tried to reinstall the proprietary NVIDIA graphics drivers, I checked their proper functioning etc. but everything was ok. What can I do for "back to life" my beloved flight simulator?

[radi]

Check the latest messages on FG-devel http://sourceforge.net/p/flightgear/mai ... /32799127/, Re: [Flightgear-devel] crash in SGPropertyNode::fireValueChanged. Torsten is working on a fix for this. Since you can compile from GIT, you're invited to test and report results.

[Johan G]

I think I have seen it mentioned on the forum that Open SceneGraph (OSG), the library FlightGear uses for the graphics, has problems in its latest release(s). This affects not only FlightGear. Many users of OSG have reported severely lowered frame rate, some having only a third of the frame rate they used to have. I am quite sure that both the OSG people and the FlightGear people are working hard on trying to find the bug(s) causing this.

Edit: radi beat me to it.

Edit 2: See also these topics:

• questions about performance with openscenegraph
• strange differences

[Hooray]

A number of users have reported similiar performance issues once they updated OSG - however, if you're building from source, you could just as well be affected by the troubleshooting going on on the devel list currently:

Several FlightGear users have pointed out inexplicable FG "slowness" that seemed related to the property rules subsystem - which is a subsystem that Torsten originally wrote/ported, so he investigated a little and managed to track this down to a pretty serious bug in the effects subsystem that may end up registering thousands of identical listeners, despite effects/shaders not even being in use necessarily.
So the property rules code wasn't even the culprit but obviously it deals with properties, so easy to mis-identify as the troublemaker.

As some of you may know from working with Nasal code: listeners are not in and of themselves expensive, but running identical listeners over and over again each frame is getting unnecessarily expensive quickly. This doesn't just apply to scripting space, but also to C++ space - here, it's the sheer performance offered by native C++ code that makes it much harder to identify such problems, because code that would bring the simulator down to its kneeds in Nasal may very well still be "fast enough" for most people with fast computers, despite being still very much "broken", and plain wrong.

Also, several core developers have now independently confirmed that FlightGear will normally be CPU bound for most people under these circumstances (that is, unless you happen to be using such a powerful computer that it isn't bothered by running thousands of identical listeners/callbacks per frame).

As can be seen on the devel list, Torsten has been spending the last weeks troubleshooting the effects system, which isn't exactly straightforward because its original developer is not currently involved in FlightGear, and the code is pretty sophisticated and even multi-threaded (which means that parts of the code may be running concurrently on different CPUs) - however, Torsten did report pretty significant performance improvements recently - he's just pushed his work to a new branch so that other developers (and people building from source!) can have a look and test his changes and report feedback/issues - this will probably mean that it may take a few weeks until all the feedback has come in and implemented - but performance should be improved significantly by then - which also addresses the whole "when will 3.2 be released" question.

[Johan G]

That sounds very reassuring.