[sldev] Texture caching

Tateru Nino tateru.nino at gmail.com
Tue Mar 20 06:59:55 PDT 2007


Well, not 100% from scratch. The textures are cached on disk - which 
saves a lot of bandwidth, but does not seem to give a major time-gain 
considering how long it takes to initialise, load and decode each texture.

The VFS is pretty deep voodoo. I've not delved into it yet. Heck, I've 
stared at the source-code for like ten minutes only. That's how I found 
this apparent cache-invalidation - but then, I knew what I was looking for.

Gary Wardell wrote:
> Hi,
>
> It sure looks like it works that way.
>
> I have two houses and I just went to house A, let it fully rez, TPed to house B, let it fully res, TPed back to A and it sure
> looked like it started all over again from scratch.
>
> Since you bring up caching, any ideas why if I set the cache to over 200mb it routinely gets corrupted to the point causing the
> viewer to crash immediately upon startup?  And even at 200 it sometimes does this, but not as frequently?
>
> One might think it should reinitialize the cache upon starting.
>
> BTW, Linden told me to set it to the full 1GB.
>
> Gary
>
>   
>> -----Original Message-----
>> From: sldev-bounces at lists.secondlife.com
>> [mailto:sldev-bounces at lists.secondlife.com]On Behalf Of Tateru Nino
>> Sent: Tue, March 20, 2007 8:52 AM
>> To: sldev at lists.secondlife.com
>> Subject: [sldev] Texture caching
>>
>>
>> Umm. Someone correct me if I'm wrong.... Actually, _please_
>> someone tell
>> me that I'm wrong.
>>
>>                 case LLAgent::TELEPORT_START_ARRIVAL:
>>                         // Transition to ARRIVING.  Viewer
>> has received
>> avatar update, etc., from destination simulator
>>                         gTeleportArrivalTimer.reset();
>>
>> gViewerWindow->setProgressCancelButtonVisible(FALSE, "Cancel");
>>                         gViewerWindow->setProgressPercent(75.f);
>>                         gAgent.setTeleportState(
>> LLAgent::TELEPORT_ARRIVING );
>>                         gAgent.setTeleportMessage("Arriving...");
>> This >>>>        gImageList.mForceResetTextureStats = TRUE;
>>                         break;
>>
>> Now, I've glanced through. Doesn't this result in setting the
>> max memory
>> cache size for textures back to zero, essentially discarding all
>> in-memory textures?
>>
>> Wouldn't it be better to let the least-recently-seen
>> algorithm take care
>> of invalidation?
>>
>> So, am I wrong? Is this _not_ causing the viewer to discard
>> all textures
>> cached in-memory during a teleport? (Evidence suggests strongly that
>> in-memory textures are being discarded on a teleport, and I'm pretty
>> sure that it's not necessary given the algorithms to manage
>> that storage
>> - I let a location load for minutes, teleport away and teleport back,
>> and spend almost as many minutes watching those textures from
>> 30 seconds
>> ago load and decode from the disk cache)
>>
>>
>> --
>> Tateru Nino
>> http://dwellonit.blogspot.com/
>>
>> _______________________________________________
>> Click here to unsubscribe or manage your list subscription:
>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev
>>
>>     
>
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev
>
>   

-- 
Tateru Nino
http://dwellonit.blogspot.com/



More information about the SLDev mailing list