hi curt, why i think that this shouldn't impact performance:
1. afaik the database pager now runs in its own thread 2. most texture-data will be loaded before the screen gets bright 3. i assume adjacent tiles will have similar materials (in real world, changes to ground material aren't abrupt) -- so loading the next tile will require only few new textures. 4. i tested this on my machine, and it was just fine why i think changing this is a good thing: 1. at LOAV where i tested this, memory usage after startup dropped by 24 megs 2. we might want to have more different ground textures and material types in future. 3. globals->get_matlib()->load_next_deferred() in fgMainLoop iterated through 210 materials during each frame, just to see that there is *nothing* to do. 4. matlib held a reference to each SGMaterial, which in turn held a reference to osg::State (ok so far, and enough for never being freed during runtime). the contained osg::State held a reference to the SGMaterial defining it. this made it impossible for SGMaterial to ever get deleted - even on exit (yes, i know the kernel takes care of freeing memory left over - but this isn't good practice, anyway). i saw the leaks in valgrind, but it took quite some time for me to find the reason in the code. i'm not yet sure how unloading textures could be done. i know it must be done in a way that won't unload and load the same texture too often. the osg does caching though, so the impact might be lower than expected. the hardware i tested this on is rather new (macbook pro, core 2 duo with nv 8600M GT 512mb, 2g ram). if you want, i can test this on some older hardware (atholon xp 2000+, geforce 6200 128mb, 768 mb ram) regards, -till On Tuesday 22 January 2008, Curtis Olson wrote: > On Jan 21, 2008 4:03 PM, till busch wrote: > > hi all, > > Hi Till, > > I don't know all the nuances of the OSG branch and OSG usage, but > originally the common material library textures were all loaded at start > time so they'd be available at any time and not hit the fps like they would > if they needed to be loaded on demand. Then we bumped up the reference > count by one so they would never be deleted from the system. > > Regards, > > Curt. > > i have continued my random optimizations to flightgear (and simgear, this > > > time). > > > > changes in the attached diffs > > ================= > > > > in simgear: > > * made textures load on demand when SGMaterial::get_state() is first > > called > > (the only drawback so far is get_state() becoming non-const) > > * osg::State held a reference to its "parent" material in userData - > > this prevented the reference count for SGMaterial from dropping to 0 > > Regards, > > Curt. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Flightgear-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/flightgear-devel
