Hi, good news - I've done more debugging in the tile cache module and think I already found something...
I'm seeing two issues with the tile cache, sometimes causing active scenery to be kicked when the cache is full - and this results in the missing patches. I'm also seeing cases where all active scenery tiles are dropped. This can also happen when cycling through the tower view - so this doesn't always help. Both issues are timestamp related (maybe depend on frame rate, system load, slow USB disks :-) or so...). * First problem is that the tiles' timestamps are only updated when the tiles are freshly loaded from disk or they are actively displayed (some magic osg "CullCallback" does that - haven't fully understood this yet). So when a tile belonging to the current position was not displayed for a while, its timestamp is old. When the view then moves or teleports into a new position, and then back to the original position, the same tiles get scheduled again - but are still found in the cache. Since their timestamps remain old, they are kicked from the cache soon afterwards, when more tiles are loaded. This is what causes the "random scenery tiles disappear" effect... => I'm testing a fix now, which updates a tile's timestamp whenever it is scheduled to be loaded, but then found in the cache. * The second issue is about the timestamps updated through this magic osg "CullCallback". These timestamps can be newer than the current time used by the cache module for loading new tiles (seems to be a frame ahead or so). When a new set of tiles is scheduled to be loaded, and the cache is already filled with many "future timestamp tiles", then the new tiles immediately kick each other from the cache (are never really loaded). When this happens, all scenery for a new position is lost (complete whiteout)... Is all the tile cache and osg code single-threaded? If these osg callbacks, the cache management and tile loading were not in the same thread, it would explain where future timestamps could come from (maybe on slow machines only). If it's all single-threaded then I'll have another look to locate this. Another option I'm already testing is introducing a flag to lock all tiles belonging to the current view position in the cache. The primary condition checked by the cache would then be to never kick tiles belonging to the current position (i.e. current inner or outer ring). Timestamps remain a secondary condition to pick from tiles not belonging to the current position. This would make things a lot more robust than relying on whacky timestamps alone. FG only supports one view position at a time, right? Multiple view positions (e.g. one screen for the tower view and a second screen for the plane) would complicate a "locked to cache" flag quite a lot... Maybe someone could comment on the threading issue. I'll do some more testing, and then hope to propose a patch... cheers, Thorsten ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
