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

[Argent Stonecutter]

On 2008-06-13, at 00:57, Buckaroo Mu wrote:
> MY PLAN: When receiving a texture from the region/asset server, it  
> would be first decoded, then store the llRawImage data - the first  
> x number of bytes (however many are currently used for JPG2000  
> texture headers) in the texture.cache file, with the remaining data  
> stored in the cache/textures/x/uuid files.

What is the advantage of retaining the texture.cache file? Simply a  
place to store small textures?

> The immediate impact I can see of these changes is a massive  
> increase in the render speed for previously-cached textures -  
> although there may be some slowdown for new textures, if the  
> JPG2000 format is designed to allow decoding to proceed from a low- 
> resolution to a higher resolution as the file is downloaded the  
> first time.

That is a major reason for using JPEG2000.

> If I'm wrong about that, please correct me (as with anything in  
> this post). In other words, the texture will not progressively  
> decode as it's downloading - it will have to download completely  
> before it is decoded.

I don't think you should consider abandoning progressive decoding, it  
would be too big a break in the system. Possible alternatives:

* Don't bother caching textures on disk until they have completely  
downloaded.
* Cache incompletely downloaded textures separately.