[sldev] Cache speed experiment & results...

[Sean Lynch]

On Tue, Jun 3, 2008 at 10:15 AM, Robin Cornelius <robin.cornelius at gmail.com>
wrote:

> Format must be capable of saving alpha channels as well. i don't
> believe standard jpeg does this. You also have the overhead of an
> additional encoding which may only be done once, but if you are
> flicking around would be come a headache and would just get turned
> off. Also re encoding, need to be careful if it was lossless image,
> especially sculpties or they will just turn to **** with compression
> artifacts.
>
> Most (processor) efficient way to save files is to just save the
> LLRawImage data as it is, then it can be directly recalled into a new
> LLRawImage when its recalled. This should maximize speed and disk
> space usage at the same time ;-)
>

I suspect PNG with a zlib compression level of 1-3 would be faster overall
due to saving the time to read the data off the disk. Of course, the
compression level only affects compression speed.

Perhaps it's time to revisit the format textures are stored in on the asset
system. Or maybe we'll do that after allowing externally hosted HTTP
textures. I believe the main advantages of jpeg2000 are the less distressing
artifacts for high compression and the ability to decode progressively
without looking like crap during the download. High compression factor, as
people have mentioned, is pretty irrelevant, so progressive jpeg with a
75-90% quality level and some postprocessing might be just as good with far
less CPU usage?

I thought we already had a separate texture decoding thread; isn't that what
"enable multiple threads" does in the advanced menu?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080603/2cd81264/attachment.htm