Slow Texture loading in recent viewers (1.21 and later)

You don't have a bug tracker, there, Shockwave; you have a customer service ticketing system. That's not what JIRA is for and it's not what LL wants to offer free accounts. What you describe is very much like what I get when I submit a ticket through the Second Life Support Center.

Thank you for your reply Ramzi. It's probably one of the most respectful replies I've seen from Linden Lab recently. So I'd like to reply point by point-- with equal respect-- to address some of these issues.



In truth, we don't expect it to be a customer service vehicle. But customers do expect it to be a customer-friendly bug-report vehicle... which most are of the opnion it is not. We're unrealistically expected to keep our posts "squeaky clean", free of emotion and ire. I fully agree that the JIRA should be moderated, and that trolling and flaming should not be tolerated. But customers are humans and we have dealt with these bugs for a long time. So Linden Lab should be aware and take it for granted that by the time a customer has to file a bug, s/he might be somewhat frustrated. This calls for thick skin, empathy, and a responsive triage team. Customer support-- no. It's a bug facility. But it needs to be more customer-friendly and responsive than I have seen. And for a certainty, a little bit of customer support might be considered as going with the turf.




Actually Ramzi, they are. I'm the one who initially posted the JIRA of this discussion... and I was banned months ago by Alexa Linden. This was done under conspicuous circumstances... two days after I had spoken with her personally, in-world, face-to-face (a very polite and friendly conversation) after she had banned one of my alts from JIRA. She did so without warning, without explanation, without reference. During that conversation, she personally promised to reinstate that alt. A day or so later, again without warning, without explanation, without reference, she banned my Wayfinder identity from JIRA as well... and I had not posted anything to JIRA during that time. That kind of thing is highly suspect. Customers do not like being lied to.

I filed a nine-page, certified letter appeals with Linden Lab. They didn't even have the courtesy to reply. I never heard a word. When I posted a couple of blogs detailing the situation, I received email notices a few days later that again, Alexa Linden, had "resolved" eight of my JIRA posts en-masse, within a period of 15 minutes. Those "resolved" posts included "cannot duplicate issue" (question: how does one even TRY to duplicate several issues within a period of 15 minutes?). Of the 8 posts she resolved, only one had even a hint of legitimacy.

Ramzi, how are customers supposed to respond to such unethical activities? I (and many others who heard about it) came to the conclusion that JIRA is directed by employees who use their position to harass and enforce their personal opinions on customers-- as well as to falsely "resolve" issues just to reduce work load. This is a disservice not only to customers-- but to Linden Lab, whose product can be very negatively impacted by such activities.

As a second example: the recent banning... again without warning... of several customers from posting to JIRA because they responded to (scuse the term) "JIRA Nazi" activities by Gorden Wendt. Ramzi, I agree that some of their posts were direct attacks upon Gordon... but frankly he was asking for it. His abusive activities on the JIRA was a direct attack and offense to other customers, who were repeatedly telling him to cut it out. He repeatedly used the tech functions of JIRA to try and enforce his personal opinion on the entire JIRA-- regardless of what others thought.

Their response to him was very understandable and very predictable. Incorrect according to the TOS? Yes. But Ramzi, rules are made to serve the company and customers. IMO, the proper response to that-- especially considering the circumstance-- would have been to delete the offensive posts, make an official Linden Lab ruling and set the issue to Showstopper (which was the majority opinion), and publicly caution all users against any further flames or trollish actions (reminding them of the need to adhere to TOS concepts). That most likely would have been proper and sufficient action-- and would have not only gotten the point across but would have brought several respectful and earnest apologies from users involved. Banning people without warning... that's a very harsh "last recourse" step. IMO, it was unwarranted in that case and only earned the JIRA further disrespect by LL customers. The solution of course would be to engage damage control by reinstating those posters with a polite warning. Not a one of them was offensive to Dan Linden or Linden Lab itself.



I respectfully disagree. I think messages were deleted that did no more than disagree with what Dan Linden was telling us... and that countered his claims (and maybe even voiced frustration at such claims). Somewhat overkill. Someone disagreeing with a Linden and exposing apparent "miscommunications" is not against TOS. Employees of Linden Lab are expected to deal with customers honestly and truthfully. When that doesn't happen... customers do have the right to counter such claims and even chide that employee for NOT dealing with us honestly. That's called "consequences for actions". Any Linden Lab employee should be considered liable to customer reactions when customers are treated badly. That's just life. Customers DO complain when things don't go right.



The main point I was making here is that of people changing an editing an original post that *I* made... in effect doing so in my name. That is improper and (excuse me being blunt) unethical. My original post should stand in original form... with addendums added in the way of comments. In truth, the entire JIRA concept has been changed by others (including Linden Lab) to something different than the original post.

The orignal post presented that textures have ALWAYS worked poorly... but that this problem increased with version 1.20. Since then Dan has challenged users to prove that fact. Frankly, I think more than enough proof has been provided by NON-PAID CUSTOMERS to warrant Linden Lab focusing on this issue with all dilligence. But as is obvious with Dan's most recent post ("Ooops! We're not really working on HTTP after all! My mistake!" it's apparent this issue is STILL not being taken seriously enough.

So no, we as customers are not going to spend more of our time, our effort, to provide hard data that Linden Lab should be pursuing itself... with ALL the bells and whistles statistical equipment plugged in. We're not being paid for this. We report the bug. We report our experience. After that, it's up to Linden Lab employees to do their job. That's the bottom line of it.




And that was the purpose of the post in the first place. IMO, Dan's separating the issue into several "meta bugs" was a poor step. All it did-- especially after this much time-- was further confuse the issue and remove the potential of seeing a continuing pattern. On this very forum I relegated the issues to three primary areas-- all of them interconnected. Frankly, I think that JIRA has served its purpose... which is to make Linden Lab aware of a serious situation. So why the continued demand for yet more and more data? How difficult can it be to trace down a serious bottleneck and redundant load attack on ones own servers? (I speak from experience here. A newb/amateur I am not). In short Ramzi, and I'm speaking as a businessman with no disrespect intended-- it is way past time for Dan Linden to be pumping customers for more "data"... and dive into getting this problem fixed. Additiona customer feedback is not required, and is just a waste of our time (as well as apparently, chaing a white rabbit-- since LL STILL isn't fixing the HTTP protocol issue as we were promised).




I fully agree. I myself stated in the JIRA months ago that I didn't know as HTTP was "the" solution. But it is a certainty that switching to a non-redundant protocol would help a lot. In addition, the cache problem is going to have to be fixed, as well as the serious graphics memory leak. All of these things are interrelated. But you are absolutely correct: fixing ONE problem could significantly improve the overall experience. That's why customers have been so vocal in that JIRA. We were TRYING to help. (Of course, again, Alexa kind of trash canned that when she banned the original poster from JIRA without stated cause, reason, or valid appeals process. That could be one reason LL has so many problems Ramzi... shutting down those who are viable sources of information).



With all due respect, customers have seen no progress. And after learning that oops... Dan has been misleading us all these months and the HTTP issues isn't really being worked on, his "mistake"... I think most of us aren't really believing anything that comes out of the direction of Linden Lab these days. That's a statement of fact Ramzi. This kind of stuff is what causes customers to distrust statements from Linden Lab. I would wager it will take Dan Linden some time and effort to get anyone to believe a word he says from this point onward.

Again Ramzi, thank you for your response. I hope my response is perceived as it's intended... a direct, factual, business-level post discussing in a frank manner our experiences with the JIRA system, customer impressions and opinions of such, the impact of such activities on Linden Lab customers... our current position as customers in this matter. As far as we're currently concerned, we've seen no accomplishment in this and we've suddenly learned that what we've been told for months (that HTTP was being address and was soon due to be fixed) was absolutely not true. So it's understandable I think, that customer reactions on that JIRA were both predictable-- and warranted. Thus I would encourage Linden Lab to reconsider some of the decisions made there-- and in truth-- reconsider its entire JIRA policy. The JIRA should be for the customers... not for the smooth sailing of the techs and LL employees. It's where we report BUGS. It's a "complaint" department in effect. I think that reality needs to be recognized.

Thank you for your reply Ramzi. It's probably one of the most respectful replies I've seen from Linden Lab recently. So I'd like to reply point by point-- with equal respect-- to address some of these issues.



In truth, we don't expect it to be a customer service vehicle. But customers do expect it to be a customer-friendly bug-report vehicle... which most are of the opnion it is not. We're unrealistically expected to keep our posts "squeaky clean", free of emotion and ire. I fully agree that the JIRA should be moderated, and that trolling and flaming should not be tolerated. But customers are humans and we have dealt with these bugs for a long time. So Linden Lab should be aware and take it for granted that by the time a customer has to file a bug, s/he might be somewhat frustrated. This calls for thick skin, empathy, and a responsive triage team. Customer support-- no. It's a bug facility. But it needs to be more customer-friendly and responsive than I have seen. And for a certainty, a little bit of customer support might be considered as going with the turf.



Actually Ramzi, they are. I'm the one who initially posted the JIRA of this discussion... and I was banned months ago by Alexa Linden. This was done under conspicuous circumstances... two days after I had spoken with her personally, in-world, face-to-face (a very polite and friendly conversation) after she had banned one of my alts from JIRA. She did so without warning, without explanation, without reference. During that conversation, she personally promised to reinstate that alt. A day or so later, again without warning, without explanation, without reference, she banned my Wayfinder identity from JIRA as well... and I had not posted anything to JIRA during that time. That kind of thing is highly suspect. Customers do not like being lied to.

I filed a nine-page, certified letter appeals with Linden Lab. They didn't even have the courtesy to reply. I never heard a word. When I posted a couple of blogs detailing the situation, I received email notices a few days later that again, Alexa Linden, had "resolved" eight of my JIRA posts en-masse, within a period of 15 minutes. Those "resolved" posts included "cannot duplicate issue" (question: how does one even TRY to duplicate several issues within a period of 15 minutes?). Of the 8 posts she resolved, only one had even a hint of legitimacy.

Ramzi, how are customers supposed to respond to such unethical activities? I (and many others who heard about it) came to the conclusion that JIRA is directed by employees who use their position to harass and enforce their personal opinions on customers-- as well as to falsely "resolve" issues just to reduce work load. This is a disservice not only to customers-- but to Linden Lab, whose product can be very negatively impacted by such activities.

As a second example: the recent banning... again without warning... of several customers from posting to JIRA because they responded to (scuse the term) "JIRA Nazi" activities by another user. Ramzi, I agree that some of their posts were direct attacks upon that person... but frankly his activities were abusive and offense to other customers, who were repeatedly telling him to cut it out. He repeatedly used the tech functions of JIRA to try and enforce his personal opinion on the entire JIRA-- regardless of what others thought.

Their response to him was very understandable and very predictable. Incorrect according to the TOS? Yes. But Ramzi, rules are made to serve the company and customers. IMO, the proper response to that-- especially considering the circumstance-- would have been to delete the offensive posts, make an official Linden Lab ruling and set the issue to Showstopper (which was the majority opinion), and publicly caution all users against any further flames or trollish actions (reminding them of the need to adhere to TOS concepts). That most likely would have been proper and sufficient action-- and would have not only gotten the point across but would have brought several respectful and earnest apologies from users involved. Banning people without warning... that's a very harsh "last recourse" step. IMO, it was unwarranted in that case and only earned the JIRA further disrespect by LL customers. The solution of course would be to engage damage control by reinstating those posters with a polite warning. Not a one of them was offensive to Dan Linden or Linden Lab itself.



I respectfully disagree. I think messages were deleted that did no more than disagree with what Dan Linden was telling us... and that countered his claims and voiced frustration at such claims. Somewhat overkill to remove any post even mildly controversial. Someone disagreeing with a Linden and exposing apparent "miscommunications" is not against TOS. Employees of Linden Lab are expected to deal with customers honestly and truthfully. When that doesn't happen... customers do have the right to counter such claims and even chide that employee for NOT dealing with us honestly. That's called "consequences for actions". Linden Lab employees should be considered answerable when customers are treated badly. That's just life. Customers DO complain when things don't go right... and when they perceive that they are not being dealt with honestly.



The main point I was making here is that of people changing an editing an original post that *I* made... in effect doing so in my name. That is improper and (excuse me being blunt) a bit unethical. My original post should stand in original form... with addendums added in the way of comments or supportive documents. In truth, that entire JIRA concept has been changed by others (including Linden Lab) to something different than the original post.

Textures have ALWAYS worked poorly. This problem increased significantly with version 1.20 (my educated guess would be that's about the time someone at LL did something that began the delay-of-service attack on LL's own servers by redundantly demanding texture reloads).

Since then Dan has challenged users to prove that 1.20 worked worse than 1.19. That challenge is a outdated and irrelevant to the current issue. The system has undergone several changes since I first posted that JIRA *6 months ago*... and the difference between 1.19 and 1.20 is no longer be an issue. What IS the issue is what's going on now, under current viewers. I have stated openly, on both blogs and forums, that subsequent tests indicated the problem was affecting ALL viewers, including 1.19 (which Dan would have been very aware of if I had been able to answer such repetitive questions within the JIRA. That's why it's bad to shut out users without blatant reasons for doing so).

I think more than enough proof has been provided by non-paid-customers to warrant Linden Lab focusing on this issue with all dilligence. But as is apparent with Dan's most recent post ("Ooops! We're not really working on HTTP after all! My mistake!" this issue is STILL not being taken seriously enough.

So no, we're not going to spend further time and effort to provide hard data that Linden Lab should be pursuing itself. We're not being paid for this. We're customers. We report the bugs. We report our experiences. Some 250 people have voted on this issue. That's a strong indication this problem actually exists. The information present thus far on the JIRA indicate WHERE it exists. After that, it's up to Linden Lab programmers to do their jobs. That's the bottom line of it.



Respectfully, Ramzi I reported the basic problem... that of extremely slow texture loading... MORE than two years ago (before the JIRA even existed). I spoke with Lindens regarding the issue... and was told "it's on high priority". One of my alts posted the issue AGAIN here on these JIRAs more than a year ago. That I found it necessary to re-post the issue in stronger terms because the first post was totally ignored... pretty much is par for the course. So here, after more than two years since the issue was first brought to Linden Lab's attention... this turns out to be one of the most significant, deep-core, damaging bugs to ever plague Second Life. It has likely cost Linden Lab millions of customers who just got bored with slow texture loading and left. It should have been fixed more than two years ago, when I first reported the problem.

So yes... two years. And that's a conservative time quote.




Yes, that was the purpose of the post in the first place. IMO, Dan's separating the issue into several "meta bugs" was a poor step. All it did-- especially after this much time-- was further confuse the issue and remove the potential of seeing a developing pattern. On this very forum I relegated the issues to three primary areas-- all of them interconnected. Frankly, I think that JIRA has served its purpose... which is to make Linden Lab aware of a serious situation. So why the continued demand for yet more and more data? How difficult can it be to trace down a serious bottleneck and redundant load attack on ones own servers? (I speak from experience here. A newb/amateur I am not). In short Ramzi, and I'm speaking as a businessman with no disrespect intended-- it is way past time for Dan Linden to be pumping customers for more "data"... and dive into getting this problem fixed. NOW. Additional customer feedback is not required, and is just a waste of our time (as well as apparently, chasing a white rabbit-- since LL STILL isn't fixing the HTTP protocol issue as we were promised).




I fully agree. I stated in the JIRA months ago that I didn't know as HTTP was "the" solution. But it is a certainty that switching to a non-redundant protocol would help a lot. In addition, the cache problem is going to have to be fixed, as well as the serious graphics memory leak. All of these things are interrelated. But you are correct: fixing ONE problem could significantly improve the overall experience. That's why customers have been so vocal in that JIRA. We were TRYING to help. (Of course, that's kind of hard to do when we're suspiciously banned-- without stated reason or response to appeal-- from the very post that brought this to LL's attention in the first place.)



Yes, it took a while. Which is a major part of the problem-- corporate failure to recognize serious issues from customer perspective.

With all due respect, to date customers have seen no progress. And after learning that oops... Dan has been misleading us all these months and the HTTP update isn't really being worked on, his "mistake"... I think most of us aren't really believing anything that comes from his direction these days. That's a statement of fact Ramzi. This kind of stuff is what causes customers to distrust statements from Linden Lab as an entity. I would wager it will take Dan Linden some time and effort to get anyone to believe a word he says from this point onward.

In addition we learn that "too high a priority" has been given to sculpties and that in version 1.22 they will load more slowly. From a customer perspective folks... this is not good news. Sculpty loading is already very poor. I'd say Dan has quite a ways to go in solving these problems. Six months Ramzi. We've been waiting six months for a texture bottleneck to be resolved. More than two years since it was first reported. Just how patient are we supposed to be? When does it get to the point that we have the right to look the company in the face and say "You are NOT delivering what we pay for!"? How much longer Ramzi, before this problem IS fixed. So far, we see a lot of claims, no evidence. And after this recent thing with Dan, most of us aren't believing anything we don't see directly implemented. That's just how it is; that's the logical result of unfactual communications with customers.

Again Ramzi, thank you for your response. I hope my response is perceived as it's intended... a direct, factual, business-level post discussing in a frank manner our experiences with the JIRA system, customer impressions and opinions of such and the impact of such activities on Linden Lab customers. I've accurately stated our current position as customers. As far as we're currently concerned, we've seen no accomplishment and we've suddenly learned that what we've been told for months was completely untrue.

It's understandable I think, that customer reactions on that JIRA were both predictable-- and warranted. Thus I would encourage Linden Lab to reconsider some of the decisions made there-- and in truth-- reconsider the entire JIRA policy. The JIRA should be for the customers... not for the smooth sailing of techs and LL employees. It's where we report BUGS. It is in effect, a "complaint" department. I think that reality needs to be recognized-- and policy adjusted to be more customer-friendly.

I can only confirm what others have posted. Most textures do not render at all tbh unless I force them to by putting the pointer over them. I can stand in a moderately textured and prim loaded sim for 30 minutes and sometimes well over half of the textures will not self render.

I have an nvidia GeForce 9800M GTS with current drivers, 4GB RAM, Intel T9500 dual cores @ 2.6GHz and Windows Vista Ultimate 64 bit running without Aero and using the 1.21.6 viewer.

I have cleared cache, deleted the cache folder, and toggled the bandwidth down to 300 and back up at others suggestions with no improvement.

It seriously impacts on the SL experience in an extremely negative way for me to essentially treat SL like a 3D coloring book by moving my mouse cursor from one prim to the next to render the area.

I'll be selling my mainland parcel and downgrading to basic and focusing what little time I will be spending in SL to building on my rented estate parcels because there was little point if any to paying premium to begin with and less reason to do so if I will be spending less time on the grid because of this unresolved issue. That is said without any bile. It simply is not practical or economical for me to do anything else.

Dagmar, give the new RC6 a try. Tonight I was able to go into crowded stores and actually enjoy it, because I could see everything for the first time in months. They still have more to do but it's a big improvement.

Logged in with v 1.22.6

1. Sim textures in front of me, in an enclosed area, took over 5 minutes to load
2. Focused directly on a single texture, zoomed in until it filled entire screen. I gave up after 2 minutes waiting for it to fully rez.
3. Hovered over a texture. Other textures continued to load instead. Hovering seemed to have only minimal (if any) effect.
4. Clicked on textures (photos) from inventory (unless otherwise indicated... 1024 x 512). Load times were:
21 seconds
10 seconds
10 seconds
8.5 seconds
8 seconds 512 x 512
9 seconds
10.5 seconds
11 seconds
8 seconds
8 seconds 1024x1024

REVIEWING photos just viewed... resulted in the photos reloading again from scratch. Apparently the cache problem is not resolved.

Went to a mall and focused on one nicely laid out booth. Filled my entire screen with just that booth. There were 40 textures present. Waited for all textures to rez and focus. Stopped counting at 2 minutes; textures were still fuzzy. Checked back at 5 minute point; all textures were loaded.

During the 1 to 2 minute point, the textures were rezzed enough to focus in on one and shop... which resulted in that texture loading within the standard 8-11 seconds, but the loading of the entire booth-- which filled my screen-- was longer than most shoppers would be willing to stand there and wait. If textures were loading properly (multiple piping) textures should have loaded in far less than 40 seconds, since that booth was my sole focus.
Turned around to another booth behind me, repeated test. Booth contained 21 textures. All textures were loaded within 1 1/2 minutes.

Moved to another booth. Booth contained 10 textures. Loading time was 65 seconds... and then only when I zoomed in on individual textures to get them to force-load. It is difficult to test actual texture loading without zooming... because detail cannot be properly determiend. Nevertheless, zooming indicated that after 60 seconds, textures still had not loaded fully. That's over 6 seconds each in an area that should have been load-prioritized due to limited viewpoint.
Conducted additional similar tests. Results were identical.

SUMMARY:
* Difference in texture size (512x512, 1024x512, 1024x1024) appears to have no effect on the load time of the textures.
* Texture loading averaged at around 8-11 seconds, which is better than 30 to 40 by a long shot, but still not where it should be.
* Redundant texture loading is still an issue.
* Overall it is progress... but not the kind of progress I would have expected after six months of supposed effort.

My next step (tomorrow) will be to run the same tests with the 1.21 viewer to see how load times compare.

Good points Nika.

JIRA may very well be a industry-leading package (who knows?) but it is obviously meant to be used (as you accurately point out) in INDUSTRY... not as a customer-report facility.

I hate to keep saying this, but I TOLD LINDEN LAB THIS when they first switched to the JIRA. The entire Linden Lab bug-reporting system has always been just awful. It's either been too little or too much.

As a device to interface with customer experience, I will agree with the posts of prior users: it is a very poor vehicle for that purpose. It is cumbersome, has a high learning curve, is prone to abuse by opinionated amateurs, and since pretty much any part of the original post can be changed by anyone at any time-- does not reflect an accurate history of the issue.

In short, for the purpose intended, JIRA is AWFUL. If Linden Lab wants to use it for internal tracking of issues, fine and good and more power to them. But it is not a good vehicle as a front end for customer bug reporting and tracking. Not only is it prone to abuse by customers-- it is prone to abuse by LL employees-with-attitudes. Such things are very visible throughout the system.

In truth, know what WOULD be a halfway decent vehicle? A simple moderated forum with strict no-troll rules (if one can't add to solving the problem... butt out). That's basically all that JIRA is anyway (albiet an extremely complex and abuseable forum). A forum might not fulfill all needs and it may not be ideal... but it would be better than the tool customers are currently expected to use.

Some have ventured that LL decided on the JIRA because it doesn't WANT the average person to be able to report bugs. They wanted a complex system so the standard SL user would give up in frustration, leaving the bug reporting to experienced user. I can (to a very small extent) understand that. But wouldn't it be far better to have an initial triage team designed to shuffle bug reports to the proper agencies, with public feedback and experience? (And like Maggie said back there, a REAL triage team... professionals with experience in systems analysis and customer interaction).

I don't care how many are "watching" an issue. I don't care how many have "voted" for an issue. Those figures are largely irrelevant (althought voting does to an extent indicate how widespread and serious a problem is). What IS relevant is how serious the reported bug is to the performance and welfare of Second Life. To determine that, Linden Lab needs some SYSTEM ANALYSTS... people who know what the crap is going on with the real world (meaning in our case, the Second Life world).

Frankly, this texture load thing is one of the worst if not THE worst long-term bug to ever hit Second Life. It has very likely cost Linden Lab more customers than ANY OTHER BUG that has ever been reported-- literally millions. That LL seems to be unaware of that fact is to me, just astounding. Honestly, this should have been red-line prioritzed and totally fixed a very, very long time ago.

(Not to mention flaky group chat. I mean seriously Lab... what kind of impression does it give potential customers when you can't even get simple CHAT right? Forgive me for being blunt... but that's just shameful).

JIRA: BAD. Need something else for the sake of the customers and Linden Lab. In addition, LL needs to professionalize its bug prioritization and remove amateurs from the process (and I'm not talking about the customers).

OK, 2am, I've spent enough time on this stuff. LOL. If LL hasn't figured this all out by now, time for me to stop handing out free advice.

Thank you very much! This is a valuable info, so I can stop trying to figure out what this changes

This is my experience, too. I haven't done any systematic measurements, but it "feels" night-and-day better.

I agree with the felt experience. Today I was handed over a notecard with 5 images embedded. I opened all of them in one rush and they all were loaded... not fast... but solid and simultaneously. I guess in about 15 seconds they all were loaded. I have the feeling that the speed of data transfer is not faster, but these horrible stalls between the different blur levels are gone or at least very small now.

SDI, Chandra, various shuttle missions, Hubble and Webb, but I am not NASA, 'nough said. The point on the JIRA is that if I were an LL employee trying to use it for real issue tracking, I would be pulling out any hair I had because of all the end users in "my" tool. As an end user in this case, I see this as a totally useless device because it was designed to be used by a disiplined team, which clearly a group of end users is never going to be. It is simply the wrong tool for the job, and many of us have quit using it in frustration.


Nika - I have been here going on 3 years. In that time I can only recall 2 events where agitating or providing forum feedback to LL has had any effect whatsoever, (Mainland policy and openspace sims - I was truly pleasently surprised on both counts), so I have no expectation of anything being done with bug reporting. Kind of like Beta Grid which devolved to the point where people who wanted to do real tests could not, and now seems to have been abandoned as a tool, I expect eventually JIRA will be abandoned and we will have the ticket process and thats it. With all the obviously talented people in the user base, it really saddens me to see how little LL really does to encourage and uitilize that talent.

As to the topic, I see a small improvement in 1.22.6 but nothing that really makes a diff, and the issue of the pickers etc is still there.

I remember when textures would load so fast that it was a griefing tool requiring LL to throttle new ones from opening when dropped on you (all you would hear is the "thunk" sound like a machine gun and your screen would be covered in textures. Though it would I am sure cause a client freeze and require a relog if done today without the protection in place, even a couple of textures dropped on you now take forever to even start the window opening process.

I am also seeing a lot of packet loss during texture loading. This seemed to start after the November failed 1.25 server upgrades. I have both DSL (6m / 512k) and Cable (10m / 2m), without any common equipment until I hit Level 3, and I see it on both. When I drop into a spot with a ton of textures, I have seen it go as high as 135% on the meter, but generally it is between 3 and 15% with bursts to 25% or so. I have done all the tracking I can do from my end, and while the client is reporting 12% I can see less than 1% on any of the jumps to the same server from the same computer. When only a few new textures are present, I do not seem to see that issue. Interestingly enough, I can be standing with nothing changing on my end though and see the packet loss meter jump as high as 12% or so from time to time. This does not seem to be region specific, and as I have said, I have eliminated anything on my end that could be doing this. Using vehicles has become almost impossible, as has flying from place to place, since as new textures are loaded any attempt at control gets lost in the lag. I have talked to many folks in world and all are seeing this.

All in all while there have been many improvments, the SL experience has degraded because of the issues in actually using it. I am kind of used to SL having good periods and lousy periods, so while it is annoying, my level of expectation is not so high anymore I quit. However, if I were new and just seeing it for the first time, I would think "How really cool, if only it worked.." and go do something else until it was ready for prime time. Noob participation, at least in my experience, has dropped dramatically. I used to get requests all the time for help in learning content creation, but this has dropped dramatically in the last few months, as has in world sales by most people I know. To me, this says new people are not nearly as enthusiastic about SL after entering as they were in the past. But hey, what do I know....

I surely agree. Have felt that way (and told LL so) since it first came out. My specific response: this tool is complex to the point it is beyond the ability of the average SL user to figure it out. We have to remember, not all users of SL are "computer literate". Many just use the thing. And they DON'T use JIRA. But again, maybe that's what LL was aiming for.



That is somewhat amazing, isn't it DR? They have this WEALTH of professionals out here... many with decades of experience and knowledge, many retired, willing to offer their feedback and experience... and Linden Lab basically treats them like brainless rocks who know nothing. Even worse... when some users prove by track record to be able to predict future events on Second Life-- Linden Lab STILL ignores them and fails to ask their opinions before making major policy changes. I could have predicted the response to the Open Space sim fiasco in a heartbeat. What is it now... more than 4,500 sims shut down by January 1? That's over 30% of their Open sim base. 40% is the "fail point"... and we're not even close to July 1 yet. They already appear to be losing money on the deal (and they've closed down sim metrics so we can't see the figures), yet they're stubbornly sticking to their decision. LOL.

Forgive me for being blunt but that's just ignorant. I say that not as an insult, but as a business statement. It's ignorant. It's their company, they can do what they want. But any company that intentionally ignores an incredibly valuable free resource, deserves the consequences. As a good friend of mine used to say, "What were they thinking?" LOL



Well, I've been on several forums that had an effect on LL-- a negative one that instead of producing healthy dialog and response, revealed a bunch of stubborn and dishonest Linden Lab employees (I do not exaggerate). That's unfortunate. When knowledgeable users find something important enough to take to the forums... one would think that worth listening to. People go to forums because Linden Lab provides no other method of approach. But like you DR... I find the forums to be of very little or no value. In truth, the only reason I've been posting here is to help set the record straight. I read the total nonsense on that JIRA post for months without being able to make a comment. At least this forum thread has allowed us to come out and openly discuss the real issues involved... and expose the (stuff) we've seen on that JIRA since last August.



Yeah, 1.22.6 seems to be functional (from what little I've used it). More testing and impressions to come. But I have to say that I'm seeing very little overall core foundation improvement over the last 6 months. There are some nice new features added during that time (one in particular that yours truly recommended to LL more than a year ago: allow us to specify the filenames of each saved photo. That's a nice thing that should have been there to begin with). But overall... except for the obvious better-but-not-sufficient speed up of texture loading, not the kind of performance improvements we'd expect over the last year or two.

That said, 8 to 11 seconds is a LOT better than 30 to 40 seconds. It's not good enough... but it's better. At least it shows someone at LL finally started paying attention to that JIRA. I would like to think that this forum, previously-blocked information and all, might have had something to do with that as well.



Wanted to quote that entire paragraph because from first word to last... it's right on the button. Like you, I am seeing fewer and fewer ACTIVE new users. I'm seeing quite a few people "site seeing" and then moving on. Not nearly as many people who decide to stick around and learn. That could be signs of the times... or as you accurately state, seriously degraded performance. Because I can absolutely assure this: our private sims today do not run nearly as smoothly, efficiently or quickly as the first sim we set up in April 2005. And that's a fact.

Quite a 'tude there Meade. ; )

"Whiny bums"? Here's a business reality: if it wasn't a matter of logistics... many people would have already hit Linden Lab with breach of contract and breach of promise lawsuits that would have made their heads spin. Frankly, they better be glad we're JUST talking.

Fact of life Meade: when a company charges high prices and delivers cheap performance... people are going to be vocal about it. We don't pay new Mercedes prices for an antiquated Volkswagen. We're the customers. WE are the ones paying the bills. Linden Lab is doing us no favors. They're not paying us. They're not giving us anything. We are paying a whalloping price for a service. People are very dissatisfied with that service. They have a RIGHT to complain. That's how business works. You either keep promises and satisfy your customers... or you hear about it.

If you signed a lease on a building, paid a whalloping down payment, then found out it was full of roaches and the wiring was bad... and the landlord let that go on year after year without doing anything about it-- how vocal would you be? Maybe you'd even contact the health department? File a lawsuit?

So to turn your statement around, the ones that need their "whiny bums punted" are the LL employees (and managers) who are making excuses instead of delivering stable, functional, bug-free product. It's not like we didn't start off being polite. But after 5 years of poor performance... I think some frank statements and complaints are the least the company should expect, don't you?

I'm guessing that should the company clean up its act and deliver product, the complaints would diminish considerably.

Wow...all I can say is wow. I agree with Qie. This is like the difference between night and day. Thank you for the suggestion.

Still haven't performed all tests. But noticed a couple of new bugs:

* Ctrl Z no longer works to restore previous position on avatar attachments.

* Quite often, avatar heads do not rotate to face the point of focus (an intermittent problem).

And of course, sculpties are still slow.

When setting draw distance to 64m, quite often items considerably beyond 64m will appear, while nearby items still haven't rezzed. This should be fairly easy to replicate and confirm.

That's the first observations after one day of use. Textures do load faster (focused textures load in 8 to 11 seconds). Much better, not good enough. It's progress. Would have expected better after six months of work.

I experimented more tonight (during low concurrency hours... 11pm SLT). Here are the results:

1. I set my Draw Distance to 64m

2. Logged out

3. Logged in and created around me a hollow sphere prim 10m to block off all external texture rezzing.

4. Then loaded textures (sizes ranging from 512 x 512 to 1024 x 1024) directly from my inventory, in increments of 5, timing the total rez time.

Results: 5 textures seemed to load as quickly as one texture--- 8 to 11 seconds (add 2 seconds for texture clicking, just to be fair. I started counting when the last texture was clicked).

However, if 10 textures were loaded at a time, they invariably took 30 seconds to load (add 4 seconds just to be fair. Takes a while to click 10 textures.)

These figures held true during multiple tests.

HOVER / CLICK PRIORITY NOT EVIDENCED
One thing that was not evidenced: that hovering over or right clicking on a texture caused it to prioritize. It simply didn't. Rezzing of textures appeared to be totally random, regardless of cursor position.

A typical example from multiple tests: In a market, facing a wall in which 20 textures filled the entire screeen, I hovered over a texture that was unrezzed. It did not rez before others. In an effort to force it to rez, I edited the prim. Other textures still rezzed before it. It was one of the final textures to load.

Conclusion: the statement that textures are prioritzied when hovered or clicked appears by all evidence to be untrue.

Coincidental rezzing: Apparently those that think it works are experiencing nothing more than coincidental loadings of textures over which they are hovering. This is really VERY common. Consider: if looking at 20 textures and hovering on one, the chances are EVEN that even randomly, it will rez before half the other textures. There's a 33% chance it will rez before 2/3 of the other textures. So even at total random rezzing, odds are very good that texture will appear to prioritize... even though it really doesn't.

It's when one hovers or clicks on a texture and it DOESN'T rez that the proof is determined.

ADDITIONAL PRIORITIZATION INFORMATION
When setting my draw distance to 64m, I notice OFTEN items rezzing well beyond 64m while close objects did not rez until much later. In experiments, there seems to be no prioritization whatsoever, not by distance, direction, angle of view, proximity, hovering, clicking or any other identifyable form. If there is a prioritization algorithm, its effects are not visible despite repeated and thorough testing in multiple environments.

SUMMARY:
Textures are working much better. There is no denying that 8 to 11 seconds is much better than 30, 40 or more. Nevertheless, it is not fast enough to provide acceptable user experience, especially while shopping.

Oddly enough, five textures seem to load as quickly as one. Ten textures however, take considerably longer.

There appears to be no texture prioritization in place of any kind. If techs claim that there is prioritzation in place, then I would suggest that it is broken... which should come as a surprise to no one.

Do your tests again with your bandwidth set to 50. Texture priority is meaningless if your bandwidth is so high that it never comes into play.

Mine is that 1.22.6 is a great step forward. Things load quickly, and don't reload. Hover priority seems to work.

It also occurs to me that if everyone uses it or something similar, this should reduce the texture asset server load and network bandwidth usage by a factor of what? 5? 10? That can only be wonderful for everyone.

Course, I have not been grunging around in the source like some people, so I could be totally wrong.

For me, 1.22.6 is a significant improvement. See more below.

Here's the only anomaly I've noticed that I haven't seen mentioned yet: If you use the Tools menu to get to the Link/Unlink commands, the selected prims sometimes get deselected when the Tools menu is brought up, and sometimes not. I don't see a Jira about this, and did not notice it in previous clients (though I am building more in the last few days than I've been doing for a few months). The kybd shortcuts work fine.

Big improvement: With 1.21 I started to experience frequent client "freezes", where voice (and other applications) continue but the streaming video freezes, with a busy cursor, and no response to mouse or kybd. These last for up to ~20 seconds. These continue even when all other apps (including virus protection) are disabled. (Good PC w/ 512MB 8800 GT video, 169.21 drivers).

I've used 1.22.6 for several hours now, and have only experienced 2 brief freezes, both while doing rather wild cam gyrations.

And, as others have reported, textures are loading quicker. For me, however, it's still not as fast as 1.19 is (tested last night).
.

The questions I have are this:

1. Why would someone want to set their bandwidth so low it's practically unusable?
2. Why even have texture prioritizing if it isn't going to prioritize on all systems?

The point being: no matter what our bandwidth, textures should be prioritized. This means several things, in order of priority:

1. Textures upon which we hover or click should load immediately, given absolute top priority.
2. Textures directly in front of us within our focal vision should load before textures to our side or back
3. Thereafter, textures closest to us should load before those farther away, in a spiraling matrix.

An alternate method would be to ignore step 2 above and skip directly to step 3. The logical reason being that we may be facing one direction now... but the next second turn to face another direction. So it would make sense to give top priority to items hovered/clicked at all times... but then load in a spiral proximity matrix from that point on, in all directions.


No matter what our bandwidth, priority should always hold true. If it doesn't, then as suggested above, the algorithm is not designed to meet the needs of SL... and is likely broken like the rest of the texture process. It's pretty obvious at this point that whoever designed the texture system in the first place really didn't really have all his ducks in a row.

As an experiment to simulate the environment where texture prioritizing is most effective, to see if it actually happens at all. This is basic diagnostic technique.
Where did I suggest that it wouldn't? I said that it would have most impact on systems where texture download time is the main issue. Where other factors (like some really broken caching code) are more important, you may not see any benefit from the texture prioritizing.

Ah KK. I'll try it and see, just for the testing.

(But I still submit that priortization that doesn't work for most users... is borked. )

KK Argent, I conducted the test as you suggested. Pulled my bandwidth down to bare minimum 50. Mind you, this results in extremely glitchy movement and constant lag. But I did as asked.

I tested several different merchant booths of varying densities of product.

What I looked for was NOT textures that rezzed when I hovered my cursor over them or edited them. Why? Because of aforementioned "coincidental random rezzing". There is a 50% chance than any individual texture will rez prior to 50% of the textures rezzing and 33% chance it will rez in the top 1/3. So watching for rezzing textures does no good.

What I watched for instead was two things:

1. Textures that continued to rez prior to the supposedly "prioritized" texture.
2. Failure of the "prioritized" texture to rez before the majority of other textures.

FACT: If indeed there is actual texture prioritization, hovering, clicking or editing a texture should result in that texture being loaded immediately, before all others, pushed to the front of the line, every time, with the sole exception of textures already currently loading (not in que... loading). All textures in que would be taken out of que until the prioritized texture had loaded.

After carefully watching, analyzing and evaluating texture load patterns... I arrived at the same conclusion as before: there appears to be no prioritization of textures. In a few cases, the selected texture was near the last to load.

What I believe everyone THINKS is texture prioritization is attributable to random coincidence... and a failure to notice other textures are still rezzing before the hovered/clicked item rezzes.

I know that Linden Lab claims there is prioritization, but after running these tests (several under full bandwidth and several at throttling to 50), all evidence indicates that either there is no texture prioritization... or what is supposedly there is not functional --meaning either totally broken, or poorly designed so that it is of little or no use to common SL user experience.

(If anyone doubts these results, I've spent my professional career running and analyzing such tests. One of my primary skills is logical evaluation of evidential data. I'm not incapable of error... but I do have quite a bit of experience in data and environmental analysis. These tests having been run on separate days and under two different run parameters, yet still winding up with the same results... I believe the findings are accurate and valid. Texture prioritization is simply a myth.)

What on earth makes you think that texture priority will STOP the downloading of textures that are currently being fetched?

It doesn't.

It never has.

All it's doing is changing the order in which downloading *starts*.

And you can check whether the "grocery line problem" is a factor by requesting *many* textures and seeing how long between clicking or focussing on them and download starts.

If you're that worried about it, clear cache and go into the area and note the order in which a given texture downloads without focussing on it. Then clear cache and go back again and focus on a texture that loaded late on the previous run. Since the interest list on the server is based on the internal object ID objects will always be presented to the viewer in the same order, so the texture loading order should not *in the absence of prioritization* change much between runs.

What I think is going on is that since the security fix *all* downloading has been broken. Because I routinely see whole objects (not just textures) that *never* rez. Or rather, I don't see them until I TP out and back, I see myself bumping into them until then.