If, like me, you’re not the kind of person that subscribes to ATI’s or nVidia’s RSS feeds and immediately jump to the nearest computer shop as soon as the latest graphics card is released, and spend thousands of dollars every year purchasing the latest and greatest to squeeze more performance out of your computer, read on. A few simple tricks might give you that extra bit of performance that might make the difference on your current computer, and finally convince you that SL 2.0 is not as slow as you thought — it just has the settings shuffled around and assumes too low settings as the default.
In the olden days, SL would detect how much video RAM your card had, and use as much as it could, and that was all. Then the clever LL programmers found out that OpenGL (the rendering framework used by all versions of the SL viewer) supports the notion of “virtual RAM” for textures. What would that possibly be good for, since virtual RAM, as we all know, is always slower than real RAM?
When you upload a texture to SL, no matter what the original format was, it gets tightly compressed to JPEG2000, which is a reasonably good standard, specially for highly-compressed images. Having them taking as little space as possible is crucial for virtual worlds like Second Life®, where a user is constantly streaming hundreds or thousands of images all the time during the whole session. So it’s not really a question of storage — disk space is cheap these days — but really downloading time. A huge 1024×1024 texture can eat up to 5 MBytes, but be compressed to a dozen KBytes (with luck!), which transfers rather quickly.
Of course, there is a trade-off. The more you compress an image, the more time it takes to decompress it. And your graphics card requires fully decompressed textures to display them. So this means that the lovely compressed 1024×1024 texture you’ve just downloaded at a wink of an eye now will eat up 5 MBytes of your card’s RAM. Even if you’re blessed with a 512 MB card or higher, this means that you can only store 100 of those textures (actually, a bit less, since SL also uses the graphic card’s video RAM for other purposes). The remaining ones have to be stored on disk, on the cache. This cache stores the compressed textures, so, even though it’s “only” up to 1 GByte large (LL has capped it at 1 GByte for mysterious reasons), it can, in fact, keep quite a lot of textures in it. And I really mean a lot.
The trouble is that it also takes “a lot” of time to load those images from the disk cache (disks are around 100-1000 times slower than regular RAM; video RAM is quite faster than regular RAM) and decompress them again to feed the graphic card. So if you have a very old graphics card (which is my case!!) with, say, just 128 MB of RAM, it means that not many textures can be held there. Every time you move the camera, and you need more textures, the VRAM has to be flushed, and the new textures, hopefully all downloaded by now, have to be decompressed and put into the VRAM again. Every time you move around, this happens again and again.
And yes, of course, you have guessed: this causes lag. A lot of lag. It’s just client-side lag, but it’s nevertheless lag 🙂