[sldev] Texture caching

[Jason Giglio]

Texture caching doesn't use VFS anymore.

I'm actually working on this right now (well more like trying to 
understand it so I can start), we should coordinate our efforts.

All I have so far is a code cleanup patch for the texture cache subsystem.

Please get on IRC and catch me on the #opensl channel on efnet so we can 
help each other figure this out and not step on each other's work.  I 
was hoping someone else would be interested in texture caching so I have 
someone to work with on this.  The code isn't commented *at all*.

Attached is the code cleanup patch, I haven't submitted it to LL because 
I plan on making a lot more changes eventually.

-Jason

Tateru Nino wrote:
> 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:
>>> /index.html
>>>
>>>     
>>
>>
>> _______________________________________________
>> Click here to unsubscribe or manage your list subscription:
>> /index.html
>>
>>   
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Gigs_texture_cache_cleanup.patch
Type: text/x-patch
Size: 3256 bytes
Desc: not available
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070320/cf547dcf/Gigs_texture_cache_cleanup.bin