[sldev] Comments on the Texture Cache page in the Wiki.

Argent Stonecutter secret.argent at gmail.com
Sun Jun 22 09:21:15 PDT 2008


This page seems to describe a far more detailed plan that I recall  
from the discussion on SLDev.

In particular, the proposed scheme for tracking multiple formats in  
the texture cache seems overly complex... at least as a first step.

The page also seems to demand more obfuscation than is necessary.

It also involves retaining a number of inefficiencies from the  
existing cache.

The simplest solution would be a separate cache for completely  
downloaded textures. This cache would be checked before the existing  
cache, and contain nothing but a serialized version of the internal  
cache structures and data, in whatever format can be quickly read and  
written. This format may involve multiple files per UUID if that is  
more efficient.

The files are stored using a multi-level directory tree based only on  
the UUID of the file. The exact details of this tree are dependent on  
the UUID, but it would be uniquely derived from the UUID.

There is no cache index file.

Checking this cache would simply involve attempting to open the  
(main) file by UUID and reading a short header containing version  
information. If the version matches, the rest of the file is loaded  
and deserialized. If not, the file(s) are deleted and the existing  
path would continue to be followed via the existing cache.

Filling this cache would happen whenever a texture was completely  
loaded from the existing texture path. The serialized texture would  
be saved to a file by UUID, and the corresponding texture would be  
deleted from the existing texture cache.

The existing texture cache would then only contain incompletely  
downloaded textures.

https://wiki.secondlife.com/wiki/SLDEV_Discussion_- 
_Texture_Cache_Plan_of_Attack



More information about the SLDev mailing list