[sldev] Multithreading, Garbage collection, Caching

[Callum Lerwick]

On Sun, 2007-03-18 at 15:57 +0100, Dale Glass wrote:
> В сообщении от 18 марта 2007 14:59 Laurent Laborde написал(a):
> > As far as i know, the JPEG2000 decoding cost a lot of cpu time in
> > SL. What about multithreading this ?

> It already is.

This is one of the improvements of the First Look codebase. Its the only
way OpenJPEG is usable, as KDU apparently has a feature where you can
tell the decode thread to run for a number of milliseconds and return
whether or not the texture is fully decoded.

> Image decoding seems to be in a separate thread. But that's not as 
> much of a benefit as you'd think, as the client is not constantly 
> decoding stuff, only while loading new data. 

Actually with OpenJPEG in a busy area, it seems to work nonstop. I don't
know if this is just OpenJPEG being slow or a bug as well. I suspect
that the "texture swappyness" tuning is completely non-optimal for
OpenJPEG. Does swapping texture detail levels in and out of OpenJPEG
cause j2k re-decodes? That may be what I'm seeing.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070318/13ad1d5f/attachment-0001.pgp