[sldev] Cache speed experiment & results...

[Tateru Nino]

Compromise? A lighterweight compressed cache format? Admittedly, yes, 
the textures would still be coming down as jpeg2000 - which means they 
would have to be decoded and recompressed before they went in the cache 
- which is wasteful. But it's wasteful once per texture transfer, not 
once per texture fetched from the cache.

Use a PNG or vanilla jpg compressor to save space on disk (and let the 
user set the compression quality with a slider to let them decide how 
much bang-for-the-buck they want out of their chosen megabytes of 
storage), then you've got far less work to do decoding than the jpeg2000 
decompressor -- or so I presume. If I got all that fatally wrong, just 
whack me with a rolled up man page.

Dante Tucker wrote:
> I definatly second this as an option. Provided there is no technical 
> reason this can't be done :)
>
> On Tue, Jun 3, 2008 at 12:54 PM, Buckaroo Mu <sldev at bitparts.org 
> <mailto:sldev at bitparts.org>> wrote:
>
>
>
>     Given the dirt-cheap price of HD space these days, why bother
>     compressing the cache, given that the decode is so expensive
>     time-wise? Enlarge the cache maximum size, and toss out the
>     compression - at least give us an option to try it, and see. A
>     simple checkbox or debug option "UseCompressedCache" or somesuch
>     defaulted to yes - then those of us with plenty of space can try
>     it out. People are screaming about texture load times - I can't
>     imagine they wouldn't sacrifice some disk space for a large boost
>     in performance.
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>   

-- 
Tateru Nino
http://www.massively.com/