But after all these years I honestly don't trust it's actually been fixed. It may have been improved, but I have a sneaky feeling that when tested the results will be about the same as they are currently.Ilan, the explanation you give above makes sense to an extent, but falls apart when one has enough viewer cache to store a megaworld (with 1.5 TB of hard drive space, I can allocate all the graphics cache the system allows)... and when one is standing in one space without moving and that texture window is still going mad. Makes me think, "Is there an internal DDoS still going on here after all these years? Is that what's slowing down texture-on-demand?"
That was the case on SL in 2005-2010 when an SL tech and I specifically pinpointed SL's texture problems: reloading the same exact textures over and over and over (up to 32 times in a row), creating their own cascading DDoS on their own asset servers.
But I also wonder about priority logic of texture loading. It's often been pointed out that texture-on-demand loads are simply put in cue and don't have any kind of priority over other texture loading. My coder-minded question to that is: Why is that? Doesn't it make sense that someone clicking a vendor to see a product or trying to get a texture to rez on a prim would be higher priority than some set of random textures loading in the background?
In such direct-user-interactive situations, it would make sense that the on-demand texture request would immediately go to the top of the cue. The background textures can wait. In experiments we've conducted it's been discovered that a texture given top priority can usually load in less than one second. That's not going to significantly bog down either the server or viewer... and would give the user involved a far more fulfilling interactive experience. Imagine clicking a vendor and having the next texture show up instantly, every time. Or building a house and having every texture applied instantly appear. Or double clicking on a texture in inventory and having it instantly show on one's screen-- because it is a direct, user-present, on-demand asset request. Of course... due to griefers a reasonable throttle would have to be implemented, but that's easy enough to do. (Allow say, only one on-request prioritization per user/device per second.)
I wonder if Firestorm might listen to that recommendation. On-demand texture requests get immediate priority... because an avatar is present and actively involved in the request.
.
