[sldev] Texture caching

[Gary Wardell]

HI,

> > caching textures to disk mostly
> > just saves on network bandwidth.
>
> And to reduce the server load, I guess.
>
> > Decoding the textures takes quite a bit longer.
>
> Why don't you cache decoded textures on disk?  I believe typical PC
> compatible with SL viewer has more free disk space than 1GB.  I
> understand that current VFS mechanism has some difficulty to handle a
> lot of small data.

Hmm, maybe the cache mechanism needs to be fixed??
In the live build I'm running if I set the cache size > 200MB it becomes corrupt in anywhere from a few minutes to a few hours and
then crashes the viewer. Actually it sometimes gets corrupted at the 200MB size.  So I can't even run at the 1GB setting.  My HD
is 150GB and less than half full and routinely defraged so it's not a HD issue.


However, decoded textures are larger than their
> compressed forms, and the number of objects doesn't change.  (I assume
> compressed and decoded textures are stores as one object.  It should
> be easy because the viewer can calculate the size of the decoded
> texture from the header.)
>
> Storing decoded textures on disk and load them as needed will reduce
> the viewer CPU load when a lot of textures are required.
>
> > However, each texture carries additional
> > system RAM and CPU overhead, so tracking tens of thousands
> of textures
> > is problematic in itself.

I wouldn't think it would be that big a deal for additional objects if a sutable hash table is used to locate things.  And it
should be much faster than recreating them each time.

>
> Storing decoded texture with its compressed form on disk will add no
> RAM/CPU overhead.

Another possible benefit to disk is while that thread is waiting on the I/O controller to complete another thread could be
working.
The problem with thread concurrency comes when all of the threads are CPU bound (Unpacking data?)

Gary