"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

Reply via email to