[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