Jim Wilson wrote:
"Curtis L. Olson" said:
Update of /var/cvs/FlightGear-0.9/source/src/Scenery In directory baron:/tmp/cvs-serv20966/Scenery
Modified Files:
newcache.cxx tileentry.cxx tileentry.hxx tilemgr.cxx Log Message:
Make a subtle change to tile loading/unloading policy in order to make the tile
paging system much more robust when position change is very rapid and sporadic.
Recall that we must load 3d models in the main render thread because model loading can trigger opengl calls (i.e. with texture loading) and all opengl calls *must* happen in the main render thread.
To accomplish this we load the base tile in the pager thread and build a work queue of external models that need to be loaded. We never allow a tile to be paged out of the tile cache until all it's pending model loads are complete.
However, when changing position very rapidly, we can quickly create a huge backlog of pending model loads because we are changing positions faster than we can load the associated models for the existing tiles. The end result is that tiles that are long out of range can't be removed because there is still a huge backlog of pending model load requests and memory blows up.
This change being committed allows the tile paging system to remove tiles if they are out of range, even when there are pending models to load. The model loading code in the render thread can now check to see if the tile exists and discard any model load request for tiles that no longer exist.
This situation should never occur in normal operation, but could occur in "contrived" situations where an external script was rapidly changing the simulator position to then be able to query FG terrain height, and doing this for a large number of points that are distributed across a large area.
Is it possible for a "legit" model load to be lost because the model queue
gets ahead of the tiles? I know, it's a dumb question, but I won't have a
chance to look myself for a few days anyway.
That's a good question. I'm pretty sure that's something I thought through carefully when I wrote the code originally, and there shouldn't be any increased chance of a lost legit load.
Regards,
Curt.
--
Curtis Olson http://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/
FlightGear Project http://www.flightgear.org
Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
