hi since i'm already much into memory-stuff i'll add my 2 cents...
On Sunday 27 January 2008, Curtis Olson wrote: > ... > Would it be possible to > compute the locations of the trees when the tile is loaded (in the load > thread) and always have these structures available when needed? Now that we > can have such wide tree coverage, we'll be burning the memory for these > structures anyway. from my first research it seems like we are burning *lots* of memory for the trees. enabling trees results in about 137 mb of aditional allocations. with trees, valgrind reports 818 mb of allocations. this count is the figure i get from starting fg, waiting for the scenerey to be loaded and letting it run for another 10 frames before exiting with fgOSExit(0). also it is important to note that the figure shows all memory that is being allocated (on the heap, as far as i can tell). so it also shows temporary allocations. i don't have the time to dig deeper here right now. i just wanted to make these firures visible for those concerned. also note that this is with the first tree implementation (one-texture-version), i haven't tried the current one yet. > ... On Sunday 27 January 2008, Curtis Olson wrote: > One of the reasons (I think) that OSG start up times are so long is that > the loading is getting interleaved with the FDM and everything else, but we > aren't actually showing the view until the loader has loaded enough data. > So there is much wasted effort at the beginning until enough terrain is > loaded and the splash screen is removed and the terrain actually drawn. > This code has grown really complex over the years, but at some point, now > that we are using OSG, it might be worth revisiting some of these earlier > design choices. They made sense for a plib world, but perhaps not for an > OSG world with better threading support. you are very much right on this one. probably a week ago i have modified the main loop do delay everything else until the scenery is loaded. startup time is a lot better this way (14 vs. 11 secs on the fast machine) -- and from my impressions it doesn't seem to break anything. i will dig deeper into this if noone oppoeses. might take some time though, as we just got our second son :-) i think flightgear could really benefit from a rewrite or restructuring of Main. also since we are not near a release yet (is that right?), we do not need to fear this. all together i believe we have a lot of people running cvs versions. cvs can move fast until the next release is being prepared. regards, - till ------------------------------------------------------------------------- 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 Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
