by Hooray » Thu Mar 06, 2014 7:37 pm
The thing is, that even we -as programmers- do not necessarily understand all the reasons for the increasing number of crashes - sure, many seem to be related to lack of resources (CPU, GPU, RAM, VRAM), but others are clearly related to certain subsystems misbehaving, and their developers not being aware of what's happening under the hood, or even worse: threading issues, i.e. a number of threads running at the same time not being properly synchronized/serialized. These are issues that need to be understood to be solved. And right: debugging and troubleshooting is not as exciting as developing new features.
But first of all, we really need to provide the tools and means to enable non-developers to tell what's going on, i.e. in terms of CPU/GPU/RAM/VRAM resources spent when using certain features, and or aircraft/scenery. We have a number of increasingly complex and well-developed aircraft that are highly popular, such as the 777-200ER for example, but there are quite a few things done inefficiently in some of these aircraft. Likewise, we do have new scenery that's adding more resource usage - and then there's new eye candy features, needing massive amounts of resources. But ultimately, we're lacking the tools to determine what's really happening behind the scenes.
Some of us have been raising this even 2-3 years ago when new features like random buildings made the underlying issues more prominent - but overall, we now have a handful of subsystems that are competing -or even fighting- for resources, without their developers really being aware of what's going on.
So the problem is at least two-fold: New eye-candy features being developed, but also more and more complex modeling and base package development going on (shaders, effects, textures, 3D models). At some point, there's no longer a single culprit to blame, but it's a combination of ill-understood features working in conjunction rendering the simulator basically unusable. Keep in mind that we do have massively popular features like effects or particles, that are known among core developers to be leaking resources (i.e. memory).
Thus, it is too easy to say it's because of certain aircraft (extra500, 777-200) or because of certain features (effects, particles, Nasal, Canvas) - you need to be highly familiar with FG internals to understand what's going on here, and D-LEON has demonstrated that it takes a lot of work and time to end up with useful results.
Basically, we need to expose runtime statistics that monitor resource usages for the main suspects (subsystems) like Nasal, AI traffic, Canvas, but also to monitor scenery/aircraft complexity.
Technically, there's no good reason for FlightGear to crash at all - the main problem is that new -popular- features are added, and that they end up being unmaintained, because their original developers are no longer around, so we are seeing them adopted by non core developers, who are obviously not able to troubleshoot things, and our -few- remaining core developers are obviously overstretched in terms of what they can manage/maintain ob behalf of others - no matter if it's particles, effects or threaded code like the tile manager.