[opensource-dev] User Story: Improved Cache

Vex Streeter vexstreeter at gmail.com
Fri Sep 17 12:54:58 PDT 2010


I think this is actually a crucial first step to cache improvement.  The 
performance of this system would be an extremely useful baseline. For 
instance I'd love to be able to toggle between saving jp2 and raw w and 
w/out mipmap.  There can be performance benefits to storing content 
compressed on disk, though it isn't clear to me that any of the SL 
assets would win here.

I don't think it needs to be a real viewer at that level - It is pretty 
trivial to obfuscate assets at a similar level of protection as that 
currently used at a CPU cost that'll get lost in the noise (example: XOR 
asset UUID and post-header content with install-determined hash).  Once 
the infrastructure is in place, a trivial obfuscater would make it TPV 
compliant, I'd think.

On 09/16/2010 07:36 PM, Dale Mahalko wrote:
> I just don't have the motivation for it myself, but I would really
> like it if a 3rd party developer would gut out LL's texture cache and
> eliminate the VFS, and replace them with a simple disk cache that
> writes all assets in raw format, with files named by UUID on disk.
>
> * Decode all JPEG2000's once, to all levels of mipmap scale, and write
> the raw RGB mipmaps to disk as individual files (UUID+mipscale.bmp),
> discarding the source JP2's.
>
> * Decode all OGGs to WAV once, and write the raw WAV to disk,
> discarding the OGGs.
>
> * Oh, and don't ever delete any assets until your dedicated 2 terabyte
> cache drive is 99.99% full.
>
> * Let the local operating system deal with the file caching. If you
> have 4+ gig of system memory, let the OS manage it for caching
> frequently accessed world data.
>
> This cache would much simpler than the layered mess of caches
> currently used, and it would give a speed boost over the constant JP2
> to RGB mipmap decoding and discarding that is in place now. Decode
> once and don't ever do it again.
>
> ,
>
> But I know it is just a dream. LL will never let it happen since it
> will lay bare the data contents of every prim, texture, and object in
> the virtual world, rather than obfuscating asset storage within the
> current VFS / JP2 method.
>
> This viewer would get blacklisted before it ever got out the door.
>
> - Dale Mahalko / Scalar Tardis
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges
>    



More information about the opensource-dev mailing list