Of late, I have increasingly been running into some segfaults which seem to 
have to do with peak memory usage (I don't think memory leaks are a major issue 
for what I've been seeing, since some segfauls happened quite early on, and 
especially when I try pushing my limits of graphical goodies). Memory also 
appears to be an issue for other users, judging by forum response.

For me, running into swap space means basically either immediate or imminent 
crash. Sometimes I get a 30 seconds grace with framerates below 5 fps, 
sometimes Flightgear dies immediately. Apparently other binaries (the 64 bit 
Jenkins) seem to be a bit more tolerant - see for instance user experiences 
here:

http://www.flightgear.org/forums/viewtopic.php?f=68&t=17114

None of this is a problem on a fundamental level for me personally - I largely 
know my 'safe' limits for visibility  (250 km for default scenery and bare 
terrain on short suborbital hops, 120 km for long-distance flights in bare 
default scenery, 60 km in bare custom scenery or default scenery with 
buildings, 40 km in custum scenery with buildings, subtract another 10% for 
trees...), so I check a range of options I know by experience to be safe before 
the flight and am not usually troubled by crashes unless I try something new.

But I know this stuff because I do a lot of benchmark testing, am active on 
this list and have some understanding of the inner workings of Flightgear. But 
there's nothing to inform the casual user what he should do. In fact, by chance 
the combination of options we offer is quite dangerous.

* before the new edition of random buildings came out, I've played a lot with 
opening up visibility at high altitude. Even for a ground visibility of less 
than 8 km, you'd get 120 km at airliner cruise altitude if 'realistic 
visibility' is checked and the visibility limit shifted to max. in Advanced 
Weather

* at the same time, random buildings (even in a rather unpopulated area like 
the Alps and with a density around 0.8) account for half of my memory 
consumption (I tested 1.0 GB for loading a 40 km radius without buildings 
against 1.9 GB for loading the same scene with buildings). That's before trees 
and/or higher densities. Hitting a major urban area changes the picture 
drastically.

The combination of the two means instant death at high altitude, even when all 
you do on the ground looks sane - you can see a nice collection of random 
buildings nearby, have a safe visibility range, good momory consumption - and 
once you are up, the tile manager starts loading a city 120 km away you don't 
even see yet and populates it with buildings, memory consumption explodes and 
you are dead.

Both options, random buildings and a realistic view range, are in my view 
extremely cool as long as you know what you are doing with them, and I don't 
really want to abandon either. But I suspect their combination (combined with 
other memory-hungry goodies) is not something we want to confront the casual 
user with.

Do we have any ideas addressing these issues?

For instance, should I agressively limit the maximally available visibility 
range in Advanced Weather if random buildings and trees are selected? Is it 
technically feasible to let Flightgear probe the remaining physical memory and 
if we run into trouble initiate an agressive unloading of terrain, e.g. by 
forcing visibility down (since most memory-hungry stuff scales with the square 
of the visibility range, I think adjusting that is most effective)? I know this 
is not realistic, but I'd rather have sudden haze than sudden segfault? Should 
we code a few warnings into the GUI?

And other ideas? Or is this not an issue for the majority?

* Thorsten
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Reply via email to