On Saturday 23 February 2013 12:21:02 Emilian Huminiuc wrote: > So in the default scheme we load 9 tiles at startup, then we keep loading > tiles in the direction we're traveling, and those initial tiles remain > resident in the tile cache for a while (in case you decide to double back).
So there's a bug in the tile cache. When caching stuff leads to an out of memory condition, the cache is at fault. The whole purpose of such a cache is to improve performance. A crashed application has the worst performance of all. So this cache should be fixed to automatically reduce the number of cached tiles in low memory conditions. > Well, our average user might have read the manual, might have mucked about > with the visibility setting before, and he remeber that all things being the > same, visibility is what impacts performance/memory the most, so he decides > to try again, this time trying to use z/Z to limit how far the visibility > goes, maybe he gets lucky and it won't crash again, but he's in for a > surprise... z/Z doesn't work... So the manual is wrong as well. Like you said yourself, trees give a larger memory hit than terrain. So the first thing to do should be to disable trees. > You might argue that he should know better, go into the advanced settings > dialog, figure out what all those sliders and selection boxes do, etc, > etc... But remeber, our user is an average one, he wants things to just > work (with time, he might find a use for the more advanced configuration > stuff, but for now he's not interested, he just want to click something, > and be done with it), The z/Z case above might be a lucky one where he > might have read the manual. Since advanced weather seems to have a slider for maximum visibility, why not change the key binding to make z/Z control this maximum visibility? This still leaves control of visibility with advanced weather but should satisfy the people using this key for memory management (however wrong that approach may be in my opinion) > You look at view-distance/fog just as an atmospheric phenomenon, that you > think should be represented verbatim, well it's not. It's not just that in > any case, and if for it to fulfil all its roles you need to abdicate from > the verbatim aproach, well then I'm sorry but my opinion is that you > should. I never claimed that it's the only resource management device, I > only claimed that it's role is much more than just visual cue to the > environment, and that role should not be underestimated, or thrown aside... >From this whole discussion I get the impression that FG's memory management simply sucks. We have caches eating too much memory at times, several memory intensive features but no information about how much memory they really use. Yet still we push responsibility for keeping memory requirements within the limits of his machine to the user. The one who has the least chance of getting it right. The solution is not to give crude tools like limiting visibility to the user. The solution is to fix FG to be consious about how much memory is available and make the best use of it. Yes, many games simply limit visibility if memory or performance pressure gets high. But FG is a flight simulator. Visibility is a very important part of flight (at least for me as a VFR pilot). Stefan ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
