Demonstration of mouse over control.jpg:
Graphics memory slider was set to 512. I was able to "draw" "IS" into the vendor boards using the mouse over trick to speed the textures along. You can see that all the common build textures still haven't loaded yet. Though, the vendor textures I moused over are already fully rezzed. (_)

Demonstration of mouse over control II.jpg:
5 minutes later some of the common build textures have finally loaded. You can actually still see my "IS" in the vendor boards by comparing the blurred to the rezzed textures. (_)

Demonstration of mouse over control II Revisited.jpg:
(another screenshot similar to "Demonstration of mouse over control II.jpg" and include the texture console)
Here's pretty much a repeat of what I did last time. I moused over a few vendors on the bottom and waited about 5 minutes for the rest of the textures to come in. Pretty much at the 6 to 7 minute point, the build textures starting coming in sharp. (_)

Demonstration of mouse over control III.jpg:
I drop my graphics memory slider to 256, TP out, TP in, arrange my camera like before and sloppily draw a "?" this time around. Before I TPed, nearly all textures were loaded and sharp..... Did this place even cache? (O.o) Disk Cache size set to 1000MB.

Demonstration of mouse over control IV.jpg:
4 minutes pass... You can still see my "?" question mark.... (T_T)

@Dessie: I pretty much run with everything maxed out. Ultra mode graphics sets the draw distance to 255, I don't change that. With Bandwidth I keep it at 1500kbps and a 1000MB cache. Packet loss is rare for me. It probably peaks at 1.0% on a bad day, but, I'm usually not watching all that much. An example of the past 20 minutes: Packets Lost: 241/104683 (0.2%)

Second Life 1.22.9 (110075) Feb 10 2009 12:43:24 (Second Life Release Candidate)
Release Notes

CPU: Intel Pentium 4 (Unknown model) (3400 MHz)
Memory: 3070 MB
OS Version: Microsoft Windows XP Service Pack 3 (Build 2600)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce 8800 GTS/PCI/SSE2
OpenGL Version: 3.0.0

libcurl Version: libcurl/7.16.4 OpenSSL/0.9.7c zlib/1.2.3
J2C Decoder Version: KDU
Audio Driver Version: FMOD version 3.740000
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.22053 (Mozilla GRE version 1.8.1.13_0000000000)

Texture Memory: 256MB (to avoid a horrible STOP error, 640MB total VRAM)
nVidia Drivers: 182.06
Graphics Quality: Ultra
Draw Distance: 64
Anisotropic Filtering: Enabled
Antialiasing: 4x

A note on the AA. I've noticed it seems to be applied to textures on your avatar (those you bake yourself). It doesn't seem to be applied to other or already-baked textures, though.

CPU: Dual i386 (Unknown) (2000 MHz)
Memory: 1024 MB
OS Version: Darwin 8.11.1 Darwin Kernel Version 8.11.1: Wed Oct 10 18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386
Graphics Card Vendor: ATI Technologies Inc.
Graphics Card: ATI Radeon X1600 OpenGL Engine
OpenGL Version: 2.0 ATI-1.4.56

As an example, here are some of the variables we tried to control, including attempting the tests at the same time of day.

• Test Setup:
  • Location: http://slurl.com/secondlife/Bare%20Rose/91/19/30
  • Cache cleared AND relogged before each test.
  • Disk cache: 500
  • Network Bandwidth: 1500
  • Graphics Level: High
  • Draw distance: 256
  • Anisotropic filtering: Off
  • Anti-Aliasing: Off
  • Texture Memory (MB): 256

Graphics set to High	1.22.10	1.21.6
Test 1	RC10	Official vwr
All non-grey	0:30	0:41
All Sharp	2:13	0:50
Test 2	RC10	Official vwr
All non-grey	0:26	0:24
All Sharp	4:00	2:07
Test 3	RC10	Official vwr
All non-grey	:20	:59
All Sharp	1:35	2:02
Viewer Set to High	1.22.10	1.21.6
Test 4	RC10	Official vwr
All non-grey	3:12	3:01
All Sharp	3:15	3:01

It was the Test 4 which is additionally puzzling; where stopwatch times reached over 3 minutes. However, then we immediate switched back to test 1.21.6, produced times at over 3 minutes as well. It is very hard to control for server performance but also to measure the number of avatars in the region. We did notice in Test 4 that the number of avatars was about 35 during that test.

We also tested with a lower Draw Distance (= 128 m) and with Avatar Imposters on

• Test Setup:
  • Location: http://slurl.com/secondlife/Bare%20Rose/91/19/30
  • Cache cleared AND relogged before each test.
  • Disk cache: 500
  • Network Bandwidth: 1500
  • Graphics Level: High
  • Draw distance: 128
  • Av Imposters: on
  • Anisotropic filtering: OFF
  • Anti-Aliasing: Off
  • Texture Memory (MB): 256

There is a lot of fluctutation in the results on either viewer. The tests show that either viewer can behave comparably, or 1.22 better than 1.21, or vice versa. It is important to point out that these tests are not deterministic. There are many, MANY factors that can affect the texture download time including the priority of other objects in the region, presence & size of other sculpted prims in your draw distance, the performance & response time of the region, etc.

Particularly, circumstances like the presence of other avatars can have a large effect on this. The current design of the texture pipeline does prioritize textures that haven't loaded at all over the need to show higher-detail for textures that are partially loaded (blurry). This includes the textures on avatars that arrive. So if a large number of avatars cycle in at the time of your visit, it is possible to get 'stuck' for extended times to load new avatar textures; and it feels like you never get to higher resolutions of the blurry ones. This is a design flaw that is not new to 1.22, but we are working to correct it in future versions of the viewer.

I think what we can determine is that you and Maghnus are seeing fluctuations in rez time that are not uniquely determined by a new bug in code; under slightly more controlled testing, the viewer 1.22 RC10 can successfully complete all sharp, high resolutions of the textures. I'd invite & encourage you to try some additional testing like the above (including the same time of day and always clearing the cache) to see if you can narrow down a consistent, repeatable difference in a certain region. That helps us to investigate. We certainly thank you for raising this issue and letting us drill down on it as we prepare to release a final 1.22 viewer.

One thing that has happened. Coincidentally since the Debian Etch rollout. Is that things have gotten consistently slower and clumsier in the scripts, simline, and teleporing activities. I'm not sure how texture loading was affected. But, my recent trials of RC8 have shown the situation getting closer to what I've seen with RC9 and 10.

It may just have been that RC8 was released during a coincidental week's worth peak on asset performance.

Thanks for bringing us to investigate this carefully.