[sldev] Texture caching
gigstaggart at gmail.com
Tue Mar 20 09:25:58 PDT 2007
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.
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:
>> 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.
>>> -----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
>>> gViewerWindow->setProgressCancelButtonVisible(FALSE, "Cancel");
>>> LLAgent::TELEPORT_ARRIVING );
>>> This >>>> gImageList.mForceResetTextureStats = TRUE;
>>> 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
>>> Click here to unsubscribe or manage your list subscription:
>> Click here to unsubscribe or manage your list subscription:
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3256 bytes
Desc: not available
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070320/cf547dcf/Gigs_texture_cache_cleanup.bin
More information about the SLDev