[sldev] Texture Cache: A summary of The Plan as it stands

[Buckaroo Mu]

I've been browsing the code some more, and have come up with a few 
questions for those who may be more familiar with the details of the 
image pipeline.

1 - Would it be beneficial, and what are the unintended consequences, of 
moving the "Load from Network", "Load from Simulator", and decode from 
llTextureFetch to llTextureCache? This would allow llTextureFetch to 
only process images stored in llRawImage objects, and leave 
llTextureCache to deal with the details of what format a texture is 
available in. It increase the complexity of the llTextureCache object, 
but dramatically simplifies the "fetch" operation - since it would not 
have to deal with differing image formats.

Corollaries - we could effectively remove the llFormattedImage object 
use from llTextureFetch class, if I'm not mistaken. This would also 
allow the llTextureCache to take care of writing cached files by itself, 
rather than being told to by the llTextureFetch class.

2 - The code delimited by USE_LFS_READ and USE_LFS_WRITE - I presume 
that's there to allow better platform neutrality? This may sound 80's of 
me, but would there be any benefit to using #ifdef-delimited blocks to 
define platform-specific read & write functions for the local file 
system, and reduce the overhead of an additional third-party library? Of 
course, it's probably used many other places in the code, but it's just 
a thought.

I'm sure I'll think of more as I dig. I'm slowly beginning to understand 
this tiny portion of the code.

 -Buckaroo Mu