Slow Texture loading in recent viewers (1.21 and later)

Hi Wayfinder, it is true that the Issue Tracker isn't and doesn't have the toolset to be a customer service vehicle. The Issue Tracker was set up to help identify & solve bugs and feature requests-- so, it is used by our Project Managers and developers to investigate the code and its performance & functionality. However, I do want to assure you and everyone else that no one is banned or censured for stating opinions, or even expressing that they are upset/frustrated about a bug.

What we do uphold is our Community Standards (http://secondlife.com/corporate/cs.php) and Issue Tracker guidelines (http://wiki.secondlife.com/wiki/Issue_tracker#Be_courteous). So, a message that simply attacks another person or persons directly is not appropriate (even here in the Forums). Those are the only messages which have been removed in this recent case.




Yes, in fairness you are correct: You reported bug VWR-8503 on Aug-2008 (about 5 months ago; but not 2 years ago) and this corresponds to just after the original release of viewer 1.20 which occurred on 27-July-2008. So it is true that this bug report was against 1.20, and it has evolved to focus on the degraded texture performance that occured further in viewer 1.21 (and then inherited by 1.22). This is not ideal, but probably understandable since the development of code usually focuses mostly on the state of the "latest" release candidates.

What I am thankful for is that your bug VWR-8503 gives a place for many residents to track SL's texture Performance problems in one place. Inevitably, though, a broad problem like this turns out to be a result of many compounded bugs in the viewer; and perhaps even some in the Server. Thus, many other linked jiras have been created under your original umbrella ("meta" report of VWR-8503.

With resident help recently, for example, we identified a number of small but painful bugs in the viewer regarding how textures are prioritized as the server sends them. Now that these small bugs are uncovered, we have Fixes for them in the upcoming 1.22 Release Candidate (RC6). To be clear, I do not think this will *completely* solve what you reported in VWR-8503; but it will constitute an important Partial Fix that would not have happened without cooperation between Residents & engineers. It did take a while for Linden Lab to dedicate proper investigation to these bugs, but the progress in the past month is an example of the Issue Tracker working as it was designed: to exchange pointed, constructive, reproducible feedback that can lead to solving the issue.

Here are some of the small bugs that will contribute to an improvement in the upcoming 1.22 viewer:

* Fixed: Sculpted textures have too high a priority in 1.21 causing slow overall texture loading
* Fixed: Eliminate a redundant priority calculation
* Fixed: Textures with no data (gray) are not getting prioritized properly
* Fixed: Textures with priority of 0 are getting stuck waiting for network data instead of terminating
* Fixed: Negative priorities are not being handled correctly
* Fixed: Modify a debug timer to measure texture fetch time instead of network download time
* Fixed: VWR-11550: "BAD" textures on 1.22.6 Public Nightly stall texture loading
* Fixed: VWR-11419: Textures reload perpetually
* Viewer-side Fix to: SVC-3628: Downloading a single texture takes too long

Question:

* Fixed: VWR-11419: Textures reload perpetually

Is this fixed in the current RC?

You're way nicer than me, Ramzi! If I was talked to like LL was in that bug, I'd be punting their whiny bums outta there. Hm.. Maybe this is why I don't work in a job that has customer contact.

Do you know offhand which/if one of those JIRAs is for textures not getting priority boost if somebody does a hover/right-click on them? I'm curious what the root cause of that was, if it's something that can be summed up...

Also, while you're here, there was talk earlier in the thread on if hovering your mouse over a gray texture for a few seconds is any different than right-clicking it. Is there any difference in these two tricks to speed up having a specific texture rez?

Hi Argent- no, it is not fixed in the RC5 which already public. We are currently testing the fix internally, so that we can release it as part of RC6, coming soon.

Hi Meade- it sounds like you are referring to a bug like https://jira.secondlife.com/browse/VWR-11552 ? We do not yet have this one fixed.

Also I am not sure if hovering your mouse is different than right-clicking it. I will have to find out and report back later.

So much of what is painfully wrong with the Jira is exemplified on page one of this thread. If this is a matter for project managers then let them set the priortiy. Moving the discussion here is another example, fragmenting discussion and such like.

The Jira is good for techies, it's not good for you average resident and that's a gap that needs to be bridged at some point.

I've noticed that with Show Updates on, right-clicking something seems to cause a full object update. I'd bet that the a right-click causes all faces/all prims to be updated a bit more quickly (not necessarily what you want in a store) and that a hover only gets you the face/prim you're hovering over.. edit: but i'd still love to hear the official story!

Thanks for your continued effort, Wayfarer. It is unfortunate that a couple of debaters here have shut themselves out of much (most) of the constructive debate you are offering, because they have the original JIRA poster on this issue on ignore!

I am yet another SL user - who btw really loves the concept of SL - that is on the brink of abandoning SL alltogether because of slooooow and/or non-appearing textures, ever increasing memory use that eventually leads to crashes - and are tired of waiting forever for these issues to be fixed.

Kudos to you.

hey!

i have tested the actual release v 1.21.6 and the latest betarelease
both viewers have the same problem - small render interrupts, moving interrupts (every 10 - 30 secs.) when im running over my island (ctf-game)

with viewer 1.20.17 i can have runmode on and smooth rendering . camturning

its not my inet connection i have solid business line and it only happens with the newer viewers (v 1.21.6, rc)
my sim is closed while developing and runs healthy (statisticsbar) 99,9& of the time
serversoftware : Second Life Server 1.24.10.106829

system, machine :
mac osx 10.4.11
intel c2d 2 Ghz / 1GbRam ati x1600 128MbVram

(I) am a techy. I build robots and embed computers in things that leave this planet. (hint hint) And even (I) am stymied by the Jira. So I don't use it. My life is complicated enough already without needing a 90 page instruction manual on how to report a bug in SL.

Me, I'd create the website www.bug.secondlife.com and have a few pulldown menus followed by a comment block. Simple and produces far more organized output than Jira does.

This is nice to hear and let's cross fingers !
I think i have experienced a few of those things Ramzi has pointed out.
Hopefully the team is on the right track...

However, i fear they are only at 25% or so... but it's a start.
Let's cross fingers anyway

HERE HERE!!! A big piece of their favorite pie to Shockwave! I too have created, with my own hands, objects that have left this world, and a few are still out there, and I can not agree more, the JIRA is the worst tool of its kind I have ever been asked to use. Not only is it totally non-intuitive and difficult to navigate and the search poor, but anyone can change the status, marking it resolved, a duplicate, etc etc.

If I, as a project manager, were told I had to use this for my job, I would start looking for a new one, thats how bad it is. And I know for a fact, that many others who would normally contribute to bug searches, discussions, etc, do not, because of the JIRA.

Time to toss it and come up with something that actually works... not something that causes the rift between LL and its paying customers to widen. (Unless of course, that is the desired result)

We use clearquest at work. Be thankful for JIRA. Really..

It's better than just about any comparable product I've used at any Fortune 500 company. Oh god, are some of those programs horrible.

if you guys are for real, this gives a whole new meaning to "Jira isn't rocket science" <.<

and about the suggestions about pulldowns and a comment box, I thought Jira was like that but with additional details for helping organize things up, details that other people can edit use in case the bug report/feature proposal didn't had all the info at first or somthing

I cannot speak for DR. But (I) most certainly am the real mccoy, yes. And I've discarded better software packages than Jira.

I've worked in the software industry for many years, at companies with not only software development groups but also with outward-facing customer service departments, like LL's. I've used a LOT of bug/issue trackers. I humbly submit that my experience with issue trackers is more relevant than NASA's - I've had NASA as a customer, and frankly dealing with NASA is more like dealing with a university than a company.

People seem to be thinking that JIRA is some tacky little package that LL picked up, and there are much better ones littering the landscape. Actually, it's an industry-leading package that is designed to be used by people trained in its use. While it is NOT rocket science - I learned how to configure it in about an hour of reading the manual - it also is not ideal for a public issue reporting system, since it does take more than 5 minutes to learn to use. Public issue trackers are most highly utilized if they are easy peasy - but unfortunately data from such trackers usually gets lost, since it is not well enough organized to be ported into a developer's issue tracker. JIRA does have the virtue that issues can easily be ported from the PJira to LL's internal JIRA -- and LL is probably happy enough with using JIRA for internal issue tracking. So, I think that agitating to replace JIRA is wasted effort.

At the very least, if we want to continue to discuss JIRA, we should take it to another thread.

Re: texture loading --- I am glad to see the fixes you list, Ramzi - a couple of those look like they will help noticably. I am in the camp that feels that texture loading has been getting worse slowly for quite some time, so am completely willing to believe that it is caused by a multiplicity of small bugs and subtle priority decisions. (I recently loaded an old 1.19 based Nicholaz client, and was amused by the lightning-fast rez). SIgh.
.

Top menu: Graphics problems, sound problems, lost inventory, Unable to Login.

Graphics second menu: Viewer Crashes, scrambled graphics, poor performance.

Sound second menu: No sound at all, No atmospheric sounds, Cannot Voice Chat, Nobody can hear my voice

Lost inventory menu: Purchase failed to appear in inventory, Item disappeared from inventory, Item I was building vanished.

Unable to login menu: SL down, account suspended, lost password



And at the top of the page are 4 URLs - "most common problems with $topic and what usually fixes them." People then can try to fix their issue with convenient tutorial instead of making what may be an unnecessary bug report. Most people just want things to work rather than make a problem call. But here in 2 simple pulldown menus, I daresay I've covered most of the broad problems a CUSTOMER would report when there is a problem they can't solve looking at the tutorial.

If I can do this in 10 minutes by myself, why can't LL?

I agree with a lot of what you say, I'm very reluctant to use it because of the reasons you cite. If I had more time on my hands I'd probably find it more useful. The bottom line is that it's not user friendly for people who just want to report a bug, the silly arguments about what priority a report should be or someone having their bug report resolved as "needs more info" puts people off bothering to report bugs next time.

However I can see how those trying to resolve bugs find it useful, it's the initial report and the unfriiendly nature that make it a negative experience.

/me agrees. It all started for me (Post-TP lag spikes, world of gray) with the 1.21.xx run and I'm not seeing a fix yet. (>_<

I was able to be an avid grid-tourist and picture taker up until 1.21.xx came into the world. 1.22.xx improved many /other/ things, but hasn't addressed the texture loading flaws that were introduced in 1.21.xx. (=_=)

I've already voted and created the Jiras that apply to my situation. Now, I just wait and twiddle my pixels. =^-^=

I've worked with issue trackers for over three decades now, even written one for a shrinkwrap software company (remeber those?) myself.

Those are all generic criticisms that apply to any issue tracking system.

And frankly, an issue tracking system is not an appropriate substitute for actual user support. Much of the chaos in PJIRA is a result of trying to do that, especially having it as the target of "report a bug" on the help menu; this generates a spectacular amount of noise. But with free accounts having no actual support, this is a very expectable result.

A freeform "report a bug" page would be of negative value unless it's staffed with people to read the reports and extract (and I'm using the word i nteh dental sense, because--trust me--it's like pulling teeth) enough information that a support person could trage, and a developer could begin to investigate.

I don't disagree with you Maggie but some of that extraction takes place now, people file reports, move them around, point out they're duplicates. The work that goes on with tracking issues needs to be separate from encouraging people to report bugs.

Of course this isn't a straight forward task and would put more work on the existing volunteers who do a lot of good work on the Jira. If it was a simple task I'm sure it would have been implemented long ago.

In all fairness Ramzi !!

Wayfinder and also me refer to a few major iterations back.
If i am right, Way to 1.19 an me to 1.20.
Now i understand that 1.19 cannot connect to the grid anymore, ok.
To me 1.20 still is the best viewer i ever seen regarding the texture load, but ok.

In my starting carreer i was involved in reviewing/auditing an engineering process 4 years ago. Later i have been doing the same kind of things at other companies as management asked me to. Now i do something entirely different, but ok.
( ok, yes, who is she... young lady, unexperienced... i've encountered all that and this can be spared This youngster runs her own professional show these days; so she knows ! )

Your reaction is the same as i know engineers in cases they came into major problem.
"It's not a total fix, but it will help... there are other factors too"... they always say that in those cases, and many more other excuses to not let go.


What i always find out is the following.

Engineers/developers tend to stick with the latest they have... simply because they cannot let go (psychologial thing).
Now... 1.21 is almost unplayable... and cripples the experience, economy and signups who actually stay, 1.22 RC's are all total stoppers as they simply cannot be used as the texture load is even severly slower than 1.21.


The engineers/developers have to let go !!
That is almost impossible from a psychological point of view i know !
1.20 is very ok, make that the mandatory viewer again, and call that 1.21B
From there... redevelop to 1.22.
If you have to roll back to earlier server code because of that, bad luck. You can also do that quickly we have seen.
1.21 and 122 you have to ditch all you have !!! Really throw it out of the window.
YES YOU CAN !!

Instead of playing around 6 months and cripple everything, restart the iteration process from the 1.20 state.

Really, also in software land this is possible i know, however you have to really let go !! Not easy, but do it !!

IF YOU CAN'T FIX IT, DITCH IT.

Otherwise, give me M's mobile phone number (he's cute, but no not to date )
I'll give you my shoulder to cry on, ok?

Absolutely agree. And triaging the raw end-user bug reports is not something that should be left to volunteers, as good as they are.

TY for the reply, Ramzi!

I think it's a different issue.

He seems to be saying that a mouse-over should bump the priority but that that doesn't happen if CTRL or ALT is being held.

In the video he attached, you can see a the texture priority go up when the cursor is just a pointer then the cursor changes to a pointer with a + sign (ALT key) and the texture window doesn't show anything with a higher priority.

This differs from what other people are reporting here. It seems they're saying that a mouse-over (with no mention of CTRL or ALT) doesn't increase the priority. Also that a right-click on the object doesn't increase the priority. I don't seem to have these bugs - mouse-over works fine for me.

I suspect your plate is fairly full but the mouse-over & right-click tricks are something many people use in texture-crowded places like stores. Not having it work right means you're at the mercy of the system to decide what you see first.. :\

/me is a little reluctant to add a JIRA since I don't have this bug. Searching "texture AND priority AND cursor" (and "..mouse" doesn't show anything that looks like this issue. Maybe somebody comfortable with JIRA who understands the issue and has the issue can give it a poke?