"Curtis L. Olson" wrote: > > D Luff writes: > > Fair enough. I was under the impression that it was the disk > > access taking the time. > > Registering new textures with opengl can take a noticable amount of > time (especially when they are large.) Freeing memory (and any > associated garbage collection) can actually be a *big* hit at times. > It actually is a very complicated problem to do tile paging properly > in a separate thread. What we have now mostly works but has grown > pretty ugly in response to some of the practical difficulties with > doing this well.
Well, I don't know the current threading code (well, it won't run under MSVC anyway AFAIK). But I'm under the impression that on my compiles the disk access is quite a problem (noticeable 'jumps' for each tile). That's no surprise. Current disks have an access time of 10 ms. If we need - say - 10 files we'll have 100 ms. (unrealistical guess as there's caching, etc., but that's w/o the work that's done as soon as the files are loaded). 100 ms is 1/10 s and that's very noticeable. Just reading the data in an extra thread into a buffer and doing the rest in the main thread should help a bit. To avoid memory (re)allocation we can recycle that buffer. CU, Christian -- The idea is to die young as late as possible. -- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel