[sldev] Reformatting Textures for the cache

[Tinker LaFollette]

On 3/22/07, Dale Glass <dale at daleglass.net> wrote:
> An alternative would be the fixed size store above, plus compression:
> You have a 16 bit 512x512 image? That's 512KB. Add say, 16KB for any
> metadata and overhead. Now take the image, compress with say, PNG and
> put it into the slot. You'll pay for this with a huge waste of disk
> space, as you'll likely get things like 32KB images in 528KB slots,
> but fragmentation won't be a problem.
>
> But then you'll pay for this yet again: This reduces the effectiveness
> of readahead. If you have the 32KB of data, 496KB of junk, then
> another image. If they were stored continuosly, then readahead would
> read something useful.

The main point of my original idea was to use the size of the data to
be retrieved as a hash value, and fixed cell sizes with easy
swapping-out of images and minimal waste or fragmentation naturally
falls out from that.

So instead of hashing on the pixel size of the image, do it based on
the size of the compressed data (rounded up to, say, a power of two,
with some minimum threshold size like 8 KB).