|
If you were logged in you would be able to see more operations.
|
|
|
| Linden Lab Issue ID: |
DEV-20084
|
Bug: Textures are loading so incredibly molasses slow that it's seriously detrimental to the SL experience.
I almost listed this as a "showstopper" due to the extremely negative effect on SL. Similar reports have been issued before, but 1.20 brings this problem to an all-new level.
I'm going to repeat a thought that has been stated repeatedly over the last year: When a person is in a sim for a lengthy period of time and all textures have already loaded, the fact that a new texture takes up to 30 seconds, a minute or even longer to load indicates an extremely borked texture loading process. No individual texture should take more than one second to load under any circumstance.
Linden Lab recognizes there are ongoing passionate reports, frustrations, and resident-to-resident suggestions on this issue. These type of discussion comments have been moved to a SL Forum thread :
http://forums.secondlife.com/showthread.php?t=302416
The Issue tracked here is intended for active investigation of the problem. Comments below on this bug are to share technical details which may help Linden Lab to isolate the bug to be fixed.
For off-topic posts, comments, or resident-to-resident discussion & support, please use the Forum link above. Comments below which are off-topic may be deleted.
(Added by Celierra Darling: This issue appears to be a compounding of several problems with different causes, and has been made into a meta-issue (a group of smaller issues) to help organize the efforts to fix it. If you'd like to help tackle these problems, see linked issues above and the comment by Dan Linden here: action_94327 .)
Examples:
- I attended a fireworks show the other day. Textures were loading so slowly the fireworks displays all looked like gray boxes.
- Went shopping at a fast sim. Vendor textures were loading so slowly I finally got tired and stopped shopping for the day.
- I have a particle poofer. Triggered it. The SINGLE texture had barealy loaded by the time the poofer finished (10 seconds later). So I figured if I set it off again the texture would show up immediately. Nope, same response. It was as if the system had dumped the texture that it had just loaded and it went through that process all over again. That has not been the case in earlier versions of SL.
- I rezzed into an area. Green dots show avatars all over the place.. .but those avatars can take up to ten minutes to even appear on the screen in any form.
- I have a sculpty-texture avatar. Probably contains 25 different sculpty shapes. That is 25 textures. I would grant that maybe that avatar is going to take 30 seconds to a minute to fully rez. Nope... TEN minutes. Makes the avatar totally useless to me (why wear an avatar people can't even see rezzed for ten minutes?).
Further comments:
From one systems analyst to another, I would strongly encourage LInden Lab to totally reconsider how they handle texture management. IMO it would seem the entire texture display system needs redesigned from the ground up... starting with the concept that (and forgive the caps.. they are to stress the concept: IF A USER CLICKS ON AN OBJECT (such a a vendor), LOAD THAT OBJECT'S TEXTURES NOW.
It seriously should never take more than one second for any individual texture to load... especially considering that SL stores textures in extremely compressed format. Even a second is excessive; if a sim has 1,000 textures, if each of those textures took a full second to load, the entire sim would take 17 minutes to rez. 2,000 textures would take more than half an hour. That's unacceptable performance.
I might suggest that when a person first enters a sim, texture loading should be given top priority, starting with avatars. And for sure, when someone is shopping an touches a vendor or clicks to the next item, that texture should load NOW. Otherwise shoppers get tired and frustrated and walk off.
|
|
Description
|
Bug: Textures are loading so incredibly molasses slow that it's seriously detrimental to the SL experience.
I almost listed this as a "showstopper" due to the extremely negative effect on SL. Similar reports have been issued before, but 1.20 brings this problem to an all-new level.
I'm going to repeat a thought that has been stated repeatedly over the last year: When a person is in a sim for a lengthy period of time and all textures have already loaded, the fact that a new texture takes up to 30 seconds, a minute or even longer to load indicates an extremely borked texture loading process. No individual texture should take more than one second to load under any circumstance.
Linden Lab recognizes there are ongoing passionate reports, frustrations, and resident-to-resident suggestions on this issue. These type of discussion comments have been moved to a SL Forum thread :
http://forums.secondlife.com/showthread.php?t=302416
The Issue tracked here is intended for active investigation of the problem. Comments below on this bug are to share technical details which may help Linden Lab to isolate the bug to be fixed.
For off-topic posts, comments, or resident-to-resident discussion & support, please use the Forum link above. Comments below which are off-topic may be deleted.
( Added by Celierra Darling: This issue appears to be a compounding of several problems with different causes, and has been made into a meta-issue (a group of smaller issues) to help organize the efforts to fix it. If you'd like to help tackle these problems, see linked issues above and the comment by Dan Linden here: action_94327 .)
Examples:
- I attended a fireworks show the other day. Textures were loading so slowly the fireworks displays all looked like gray boxes.
- Went shopping at a fast sim. Vendor textures were loading so slowly I finally got tired and stopped shopping for the day.
- I have a particle poofer. Triggered it. The SINGLE texture had barealy loaded by the time the poofer finished (10 seconds later). So I figured if I set it off again the texture would show up immediately. Nope, same response. It was as if the system had dumped the texture that it had just loaded and it went through that process all over again. That has not been the case in earlier versions of SL.
- I rezzed into an area. Green dots show avatars all over the place.. .but those avatars can take up to ten minutes to even appear on the screen in any form.
- I have a sculpty-texture avatar. Probably contains 25 different sculpty shapes. That is 25 textures. I would grant that maybe that avatar is going to take 30 seconds to a minute to fully rez. Nope... TEN minutes. Makes the avatar totally useless to me (why wear an avatar people can't even see rezzed for ten minutes?).
Further comments:
From one systems analyst to another, I would strongly encourage LInden Lab to totally reconsider how they handle texture management. IMO it would seem the entire texture display system needs redesigned from the ground up... starting with the concept that (and forgive the caps.. they are to stress the concept: IF A USER CLICKS ON AN OBJECT (such a a vendor), LOAD THAT OBJECT'S TEXTURES NOW.
It seriously should never take more than one second for any individual texture to load... especially considering that SL stores textures in extremely compressed format. Even a second is excessive; if a sim has 1,000 textures, if each of those textures took a full second to load, the entire sim would take 17 minutes to rez. 2,000 textures would take more than half an hour. That's unacceptable performance.
I might suggest that when a person first enters a sim, texture loading should be given top priority, starting with avatars. And for sure, when someone is shopping an touches a vendor or clicks to the next item, that texture should load NOW. Otherwise shoppers get tired and frustrated and walk off. |
Show » |
made changes - 05/Aug/08 01:31 PM
| Field |
Original Value |
New Value |
|
Status
|
Open
[ 1
]
|
Resolved
[ 5
]
|
|
Resolution
|
|
Needs More Info
[ 4
]
|
made changes - 05/Aug/08 05:24 PM
|
Status
|
Resolved
[ 5
]
|
Reopened
[ 4
]
|
|
Resolution
|
Needs More Info
[ 4
]
|
|
made changes - 06/Aug/08 05:28 AM
|
Resolution
|
|
Needs More Info
[ 4
]
|
|
Status
|
Reopened
[ 4
]
|
Resolved
[ 5
]
|
made changes - 06/Aug/08 09:48 AM
|
Resolution
|
Needs More Info
[ 4
]
|
|
|
Status
|
Resolved
[ 5
]
|
Reopened
[ 4
]
|
made changes - 18/Aug/08 02:22 PM
|
Assignee
|
|
WorkingOnIt Linden
[ WorkingOnIt Linden
]
|
made changes - 18/Aug/08 02:23 PM
|
Linden Lab Issue ID
|
|
DEV-19402
|
made changes - 18/Aug/08 02:42 PM
|
Link
|
|
This issue is duplicated by VWR-2997
[ VWR-2997
]
|
made changes - 18/Aug/08 02:43 PM
|
Link
|
This issue is duplicated by VWR-2997
[ VWR-2997
]
|
|
made changes - 18/Aug/08 02:44 PM
|
Link
|
|
This issue is related to by VWR-2997
[ VWR-2997
]
|
made changes - 20/Aug/08 08:28 AM
|
Link
|
|
This issue Relates to VWR-6977
[ VWR-6977
]
|
made changes - 20/Aug/08 08:28 AM
|
Link
|
|
This issue Relates to VWR-7579
[ VWR-7579
]
|
made changes - 20/Aug/08 08:28 AM
|
Link
|
|
This issue Relates to VWR-4164
[ VWR-4164
]
|
made changes - 20/Aug/08 08:28 AM
|
Link
|
|
This issue Relates to SVC-2888
[ SVC-2888
]
|
made changes - 20/Aug/08 08:28 AM
|
Link
|
|
This issue Relates to SVC-2890
[ SVC-2890
]
|
made changes - 28/Aug/08 11:34 PM
|
Link
|
|
This issue is related to by VWR-8824
[ VWR-8824
]
|
made changes - 04/Sep/08 09:58 PM
|
Priority
|
Critical
[ 2
]
|
Showstopper
[ 1
]
|
|
Affects Version/s
|
1.20
[ 10350
]
|
|
|
Affects Version/s
|
|
1.21 Release Candidate
[ 10360
]
|
made changes - 09/Sep/08 01:58 PM
|
Link
|
|
This issue Relates to SVC-3016
[ SVC-3016
]
|
made changes - 15/Sep/08 05:07 PM
|
Priority
|
Showstopper
[ 1
]
|
Critical
[ 2
]
|
made changes - 17/Oct/08 09:04 AM
|
Attachment
|
|
royer8.jpg
[ 19633
]
|
made changes - 17/Oct/08 11:12 AM
|
Affects Version/s
|
|
1.21
[ 10370
]
|
made changes - 17/Oct/08 01:30 PM
|
Link
|
|
This issue is related to by VWR-9509
[ VWR-9509
]
|
made changes - 17/Oct/08 03:34 PM
made changes - 18/Oct/08 09:41 AM
|
Link
|
|
This issue is original of duplicate VWR-9877
[ VWR-9877
]
|
made changes - 21/Oct/08 04:56 PM
|
Link
|
|
This issue is original of duplicate VWR-9976
[ VWR-9976
]
|
made changes - 24/Oct/08 06:10 AM
|
Link
|
|
This issue is related to by SVC-3303
[ SVC-3303
]
|
made changes - 29/Oct/08 01:01 PM
|
Attachment
|
|
sl_mm.png
[ 19970
]
|
made changes - 29/Oct/08 06:47 PM
made changes - 30/Oct/08 01:00 AM
|
Link
|
|
This issue is related to by MISC-1776
[ MISC-1776
]
|
made changes - 05/Nov/08 12:30 PM
made changes - 06/Nov/08 08:24 AM
|
Link
|
|
This issue is original of duplicate VWR-10338
[ VWR-10338
]
|
made changes - 09/Nov/08 05:59 PM
made changes - 09/Nov/08 06:00 PM
made changes - 12/Nov/08 10:07 PM
|
Link
|
|
This issue is related to by VWR-10463
[ VWR-10463
]
|
made changes - 13/Nov/08 06:58 AM
|
Link
|
|
This issue is related to by VWR-10466
[ VWR-10466
]
|
made changes - 13/Nov/08 11:10 AM
|
Workflow
|
jira-2007-12-22a
[ 57997
]
|
jira-2008-11-14
[ 65118
]
|
made changes - 13/Nov/08 11:33 AM
|
Workflow
|
jira-2007-12-22a
[ 65118
]
|
jira-2008-11-14
[ 73513
]
|
made changes - 13/Nov/08 05:05 PM
|
Workflow
|
jira-2008-11-14
[ 73513
]
|
jira-2008-11-14a
[ 98929
]
|
made changes - 13/Nov/08 05:20 PM
|
Workflow
|
jira-2008-11-14
[ 98929
]
|
jira-2008-11-14a
[ 104713
]
|
made changes - 13/Nov/08 05:29 PM
|
Workflow
|
jira-2008-11-14
[ 104713
]
|
jira-2008-11-14a
[ 108569
]
|
made changes - 13/Nov/08 05:47 PM
|
Workflow
|
jira-2008-11-14
[ 108569
]
|
jira-2008-11-14a
[ 114275
]
|
made changes - 13/Nov/08 06:18 PM
|
Workflow
|
jira-2008-11-14
[ 114275
]
|
jira-2008-11-14a
[ 125712
]
|
made changes - 13/Nov/08 06:46 PM
|
Workflow
|
jira-2008-11-14
[ 125712
]
|
jira-2008-11-14a
[ 136067
]
|
made changes - 13/Nov/08 07:04 PM
|
Workflow
|
jira-2008-11-14
[ 136067
]
|
jira-2008-11-14a
[ 143359
]
|
made changes - 22/Nov/08 02:30 AM
|
Attachment
|
|
royer_22.png
[ 20457
]
|
made changes - 29/Nov/08 01:54 PM
|
Affects Version/s
|
|
1.22 Release Candidate
[ 10400
]
|
|
Affects Version/s
|
|
1.22 Public Nightly
[ 10390
]
|
made changes - 29/Nov/08 05:17 PM
|
Link
|
|
This issue is original of duplicate VWR-4164
[ VWR-4164
]
|
made changes - 29/Nov/08 05:17 PM
|
Link
|
This issue Relates to VWR-4164
[ VWR-4164
]
|
|
made changes - 14/Dec/08 11:09 AM
|
Link
|
|
This issue is original of duplicate MISC-2046
[ MISC-2046
]
|
made changes - 15/Dec/08 08:48 AM
|
Link
|
|
This issue is original of duplicate MISC-1935
[ MISC-1935
]
|
made changes - 18/Dec/08 08:09 PM
|
Priority
|
Critical
[ 2
]
|
Showstopper
[ 1
]
|
made changes - 20/Dec/08 05:49 AM
|
Link
|
|
This issue is original of duplicate VWR-11153
[ VWR-11153
]
|
made changes - 23/Dec/08 05:52 AM
|
Link
|
|
This issue is related to by VWR-11212
[ VWR-11212
]
|
made changes - 07/Jan/09 12:32 AM
|
Link
|
|
This issue is related to by SVC-3628
[ SVC-3628
]
|
made changes - 07/Jan/09 12:32 AM
|
Link
|
|
This issue is related to by SVC-3630
[ SVC-3630
]
|
made changes - 07/Jan/09 12:32 AM
|
Link
|
|
This issue is related to by VWR-11418
[ VWR-11418
]
|
made changes - 07/Jan/09 12:32 AM
|
Link
|
|
This issue is related to by VWR-11419
[ VWR-11419
]
|
made changes - 07/Jan/09 12:32 AM
|
Link
|
|
This issue is related to by VWR-11420
[ VWR-11420
]
|
made changes - 07/Jan/09 01:32 PM
|
Link
|
|
This issue is original of duplicate VWR-8824
[ VWR-8824
]
|
made changes - 07/Jan/09 01:32 PM
|
Link
|
This issue is related to by VWR-8824
[ VWR-8824
]
|
|
made changes - 07/Jan/09 01:38 PM
|
Summary
|
Textures loading worse than ever since new upgrade
|
Textures loading worse in 1.21/1.22
|
|
Linden Lab Issue ID
|
DEV-19402
|
DEV-20084
|
made changes - 08/Jan/09 04:47 AM
|
Attachment
|
|
blurry.png
[ 21340
]
|
made changes - 08/Jan/09 07:11 AM
|
Issue Type
|
Bug
[ 1
]
|
Meta Issue
[ 6
]
|
made changes - 08/Jan/09 07:22 AM
|
Link
|
|
This issue Relates to MISC-398
[ MISC-398
]
|
made changes - 09/Jan/09 06:49 AM
|
Link
|
|
This issue Relates to VWR-8841
[ VWR-8841
]
|
made changes - 12/Jan/09 05:36 PM
|
Link
|
|
This issue is related to by VWR-11523
[ VWR-11523
]
|
made changes - 13/Jan/09 07:11 AM
|
Link
|
|
This issue is original of duplicate VWR-9763
[ VWR-9763
]
|
made changes - 13/Jan/09 08:55 AM
|
Priority
|
Showstopper
[ 1
]
|
Critical
[ 2
]
|
made changes - 13/Jan/09 09:12 AM
|
Priority
|
Critical
[ 2
]
|
Showstopper
[ 1
]
|
made changes - 13/Jan/09 10:36 AM
|
Priority
|
Showstopper
[ 1
]
|
Critical
[ 2
]
|
made changes - 13/Jan/09 01:54 PM
|
Priority
|
Critical
[ 2
]
|
Showstopper
[ 1
]
|
made changes - 13/Jan/09 02:20 PM
|
Priority
|
Showstopper
[ 1
]
|
Critical
[ 2
]
|
made changes - 13/Jan/09 02:25 PM
|
Priority
|
Critical
[ 2
]
|
Showstopper
[ 1
]
|
made changes - 13/Jan/09 02:51 PM
|
Priority
|
Showstopper
[ 1
]
|
Critical
[ 2
]
|
made changes - 13/Jan/09 03:29 PM
|
Priority
|
Critical
[ 2
]
|
Showstopper
[ 1
]
|
made changes - 13/Jan/09 03:30 PM
|
Priority
|
Showstopper
[ 1
]
|
Critical
[ 2
]
|
made changes - 13/Jan/09 03:34 PM
|
Priority
|
Critical
[ 2
]
|
Showstopper
[ 1
]
|
made changes - 13/Jan/09 03:38 PM
|
Priority
|
Showstopper
[ 1
]
|
Critical
[ 2
]
|
made changes - 13/Jan/09 03:50 PM
|
Summary
|
Textures loading worse in 1.21/1.22
|
Textures loading issue
|
made changes - 13/Jan/09 03:52 PM
|
Summary
|
Textures loading issue
|
Textures loading worse in 1.21/1.22
|
|
Priority
|
Critical
[ 2
]
|
Showstopper
[ 1
]
|
made changes - 13/Jan/09 03:59 PM
|
Priority
|
Showstopper
[ 1
]
|
Critical
[ 2
]
|
made changes - 13/Jan/09 04:13 PM
|
Priority
|
Critical
[ 2
]
|
Showstopper
[ 1
]
|
made changes - 13/Jan/09 04:24 PM
|
Priority
|
Showstopper
[ 1
]
|
Critical
[ 2
]
|
made changes - 13/Jan/09 04:29 PM
|
Priority
|
Critical
[ 2
]
|
Showstopper
[ 1
]
|
made changes - 13/Jan/09 04:40 PM
|
Priority
|
Showstopper
[ 1
]
|
Critical
[ 2
]
|
made changes - 13/Jan/09 04:48 PM
|
Priority
|
Critical
[ 2
]
|
Showstopper
[ 1
]
|
made changes - 13/Jan/09 04:59 PM
|
Comment
|
[ At this point it is clear that Gordon Wendt is abusing the pjira and needs to be permanently removed if not from Second Life itself. Recommend all watchers abuse report Gordon Wendy as a pjira griefer by referencing http://jira.secondlife.com/browse/VWR-8503 as the location.
]
|
|
made changes - 13/Jan/09 05:00 PM
|
Issue Type
|
Meta Issue
[ 6
]
|
Bug
[ 1
]
|
made changes - 14/Jan/09 07:34 AM
|
Summary
|
Textures loading worse in 1.21/1.22
|
Meta-Issue: Textures loading worse in 1.21/1.22
|
|
Issue Type
|
Bug
[ 1
]
|
Meta Issue
[ 6
]
|
made changes - 14/Jan/09 02:33 PM
|
Description
|
I almost listed this as a "showstopper" due to the extremely negative effect on SL. Similar reports have been issued before, but 1.20 brings this problem to an all-new level.
Textures are loading so incredibly molasses slow that it's seriously detrimental to the SL experience.
I attended a fireworks show the other day. Textures were loading so slowly the fireworks displays all looked like gray boxes.
Went shopping at a fast sim. Vendor textures were loading so slowly I finally got tired and stopped shopping for the day.
I have a particle poofer. Triggered it. The SINGLE texture had barealy loaded by the time the poofer finished (10 seconds later). So I figured if I set it off again the texture would show up immediately. Nope, same response. It was as if the system had dumped the texture that it had just loaded and it went through that process all over again. That has not been the case in earlier versions of SL.
I rezzed into an area. Green dots show avatars all over the place.. .but those avatars can take up to ten minutes to even appear on the screen in any form.
I have a sculpty-texture avatar. Probably contains 25 different sculpty shapes. That is 25 textures. I would grant that maybe that avatar is going to take 30 seconds to a minute to fully rez. Nope... TEN minutes. Makes the avatar totally useless to me (why wear an avatar people can't even see rezzed for ten minutes?).
I'm going to repeat a thought that has been stated repeatedly over the last year: When a person is in a sim for a lengthy period of time and all textures have already loaded, the fact that a new texture takes up to 30 seconds, a minute or even longer to load indicates an extremely borked texture loading process. No individual texture should take more than one second to load under any circumstance.
From one systems analyst to another, I would strongly encourage LInden Lab to totally reconsider how they handle texture management. IMO it would seem the entire texture display system needs redesigned from the ground up... starting with the concept that (and forgive the caps.. they are to stress the concept: IF A USER CLICKS ON AN OBJECT (such a a vendor), LOAD THAT OBJECT'S TEXTURES NOW.
It seriously should never take more than one second for any individual texture to load... especially considering that SL stores textures in extremely compressed format. Even a second is excessive; if a sim has 1,000 textures, if each of those textures took a full second to load, the entire sim would take 17 minutes to rez. 2,000 textures would take more than half an hour. That's unacceptable performance.
I might suggest that when a person first enters a sim, texture loading should be given top priority, starting with avatars. And for sure, when someone is shopping an touches a vendor or clicks to the next item, that texture should load NOW. Otherwise shoppers get tired and frustrated and walk off.
|
*Bug:* Textures are loading so incredibly molasses slow that it's seriously detrimental to the SL experience.
I almost listed this as a "showstopper" due to the extremely negative effect on SL. Similar reports have been issued before, but 1.20 brings this problem to an all-new level.
I'm going to repeat a thought that has been stated repeatedly over the last year: When a person is in a sim for a lengthy period of time and all textures have already loaded, the fact that a new texture takes up to 30 seconds, a minute or even longer to load indicates an extremely borked texture loading process. No individual texture should take more than one second to load under any circumstance.
{panel:title=Extended Discussion is in the SL Forums| borderStyle=dashed| borderColor=#ccc| titleBGColor=#F7D6C1| bgColor=#FFFFCE}
Linden Lab recognizes there are ongoing passionate reports, frustrations, and resident-to-resident suggestions on this issue. These type of discussion comments have been moved to a SL Forum thread :
http://forums.secondlife.com/showthread.php?t=302416
The Issue tracked here is intended for active investigation of the problem. Comments below on this bug are to share technical details which may help Linden Lab to isolate the bug to be fixed.
*For off-topic posts, comments, or resident-to-resident discussion & support, please use the Forum link above.* Comments below which are off-topic may be deleted.
{panel}
*Examples:*
* I attended a fireworks show the other day. Textures were loading so slowly the fireworks displays all looked like gray boxes.
* Went shopping at a fast sim. Vendor textures were loading so slowly I finally got tired and stopped shopping for the day.
* I have a particle poofer. Triggered it. The SINGLE texture had barealy loaded by the time the poofer finished (10 seconds later). So I figured if I set it off again the texture would show up immediately. Nope, same response. It was as if the system had dumped the texture that it had just loaded and it went through that process all over again. That has not been the case in earlier versions of SL.
* I rezzed into an area. Green dots show avatars all over the place.. .but those avatars can take up to ten minutes to even appear on the screen in any form.
* I have a sculpty-texture avatar. Probably contains 25 different sculpty shapes. That is 25 textures. I would grant that maybe that avatar is going to take 30 seconds to a minute to fully rez. Nope... TEN minutes. Makes the avatar totally useless to me (why wear an avatar people can't even see rezzed for ten minutes?).
*Further comments:*
From one systems analyst to another, I would strongly encourage LInden Lab to totally reconsider how they handle texture management. IMO it would seem the entire texture display system needs redesigned from the ground up... starting with the concept that (and forgive the caps.. they are to stress the concept: IF A USER CLICKS ON AN OBJECT (such a a vendor), LOAD THAT OBJECT'S TEXTURES NOW.
It seriously should never take more than one second for any individual texture to load... especially considering that SL stores textures in extremely compressed format. Even a second is excessive; if a sim has 1,000 textures, if each of those textures took a full second to load, the entire sim would take 17 minutes to rez. 2,000 textures would take more than half an hour. That's unacceptable performance.
I might suggest that when a person first enters a sim, texture loading should be given top priority, starting with avatars. And for sure, when someone is shopping an touches a vendor or clicks to the next item, that texture should load NOW. Otherwise shoppers get tired and frustrated and walk off.
|
made changes - 14/Jan/09 02:42 PM
|
Comment
|
[ I think there is a little more to this than texture priorities (an issue I was pursuing). The texture console tells quite a story about aggressive cache flushing and a cyclic re-downloading of the same textures over and over until one leaves the offending area.
As the original poster was banned for stating these concerns I would entreat Linden Lab to reinstate Wayfinder Wishbringer's pJira access. It looks awfully like the messenger was fired for telling the truth, in fact, for stating the bleeding obvious.
Now if a better SL experience can be made available by allowing the use of 1.20.x, I hope it will soon be on the website available for downloading. I trashed that series long ago.
]
|
|
made changes - 14/Jan/09 02:43 PM
|
Comment
|
[ Linda Brynner:
> Most remarkeble is to see that the exe of viewer 1.21 is ~65% of that of 1.20.
> You would start to think that important components regarding texture rendering have been ditched or at least seriously affected.
Size of the resulting binary is often misleading. Smaller size could mean other optimisation settings when comliling. Whe I compile I can decide if I want smaller binary or faster code. Could be they changed something to smaller binary.
Additionally there's a huge difference if they take parts of the codes out of the binary and move them to danymic libraries that are included when the binary is started. This means the binary is smaller, but the missing code is in the library files.
Deleting/commenting out debugging routines can vastly change the size as well.
If they would have taken out so huge amounts of code, the community would have noticed for sure. There are lots of gifted developers out there looking through all changes as soon as they are committed to the repositories of Linden Labs.
Georgie Greggan:
> Now if a better SL experience can be made available by allowing the use of 1.20.x, I hope it will soon be on the website available for downloading. I trashed that series long ago.
Feel free to download the older version. Tho I don't know if the grid will let you login with the outdated release viewer and if yes, if there are some security issues when doing so. I doubt it, but I cannot guarantee.
http://download-secondlife-com.s3.amazonaws.com/Second_Life_1-20-17-98669_Setup.exe
]
|
|
made changes - 14/Jan/09 02:43 PM
|
Comment
|
[ If I remember correctly the decresed filesize of the new viewers were due to old asserts not used anymore being deleted from the package
]
|
|
made changes - 14/Jan/09 02:44 PM
|
Comment
|
[ "I don't know if the grid will let you login with the outdated release viewer"
You can (as far as I know) always log in with any viewer level (bypassing the version/release check anyway) by giving the "--channel" switch with any value after it (as in "--channel what3v3r") on the secondlife command line (i.e. in the properties of the SL launch icon or whatgever where you can specify arguments). This just skips the check, of course, it doesn't magically fix any actual problems or incompatibilities or security bugs that the older viewer might have...
]
|
|
made changes - 14/Jan/09 02:44 PM
|
Comment
|
[ I don't know why the JIRA decided to cross out some of my comment there :) but the switch in question is two dashes followed by the word "channel" (no quotes of course) followed by a blank followed by any word at all (and then followed by another blank if there are more arguments to come).
]
|
|
made changes - 14/Jan/09 02:45 PM
|
Comment
|
[ "PROPOSAL: Totally forget and ditch 1.21 & 1.22. Ditch it, burn it, scratch it, drown it, burry it...."
How about we don't and say we did?
1.21 and 1.22 has brought several improvements with them, for sculpts, for inventory fetching, much needed code cleanups, first parts of UDP > HTTP translation, Mono support, grop chat moderation, touch coordinates on objects, removal of the release keys button, return of the permanent tools menu, IM window inventory drops, several new LSL functions, saving snapshots in different formats, terraforming strength, whispering, and *dozens* of bugfixes.
So how about instead of ditching all that right out of the window there as you suggest, let's instead ...I don't know, suggest the more effective method of just focusing on fixing the texture cache and asset priorities instead?
PROPOSAL: Make this bug and the components causing it a priority in your client work, even if it wasn't on the roadmap for the 1.22 release.
]
|
|
made changes - 14/Jan/09 02:45 PM
|
Comment
|
[ lowering to critical since this is not a showstopper per the given definition. Balpein, you said you upped it due to possible buffer overrun issues, if you see any file new tickets for them and add them to the next bug triage agenda that you can find at http://wiki.secondlife.com/wiki/Bug_Triage so that they can be triaged and brought the the Lindens' attention.
]
|
|
made changes - 14/Jan/09 02:46 PM
|
Comment
|
[ Gordon -
Since when is not being able to use the browser because you can't shop or walk about without interminable waits not a show stopper? Yesterday, It took over 30 minutes for a sim I visit regularly to rez fully.
Good grief! How do we change it back? Someone who knows how - please edit this back.
]
|
|
made changes - 14/Jan/09 02:46 PM
|
Comment
|
[ Raster Teazle changed it back, but...
From my feelings I'd say, you're right, that's a showstopper, but we are collaborating here, so we must stick to the definitions, or nobody will know what the other is talking about.
The definition is:
Showstopper
ONLY the most severe, *confirmed* issues which demand immediate attention from Linden Lab. For example, inability for many Residents to login. IMPORTANT: Abusing this setting will cause revocation of Issue Tracker access. If in doubt, mark "Critical" instead.
Critical
Generally, most crashes (particularly if they're easy to reproduce and affect many), content loss, significant memory leaks, greatly reduced performance, etc.
So from the logical point of view, Gordon was correct in lowering the prio.
I hope Raster Teazle will not loose the jira access now...
]
|
|
made changes - 14/Jan/09 02:47 PM
|
Comment
|
[ I don't think I'm abusing this setting at all. This is a showstopper plain and simple and it needs to be fixed NOW!
It is affecting people here in many ways. Examples mentioned are losing sales from slow rezzing vendor textures, unusable sculpt avatar attachments because rezzing is too long. Imagine trying to put on a fashion show with sculpted avatar clothes. Would this problem be a "Showstopper" then.
I have a products that I intend to convert to lower prims using texture buttons instead of the prim buttons I currently use. I have done some tests and the results were unusable with the texture loading situation as it is now. This is a Showstopper!
The textures should load fast and should not have to reload. What is in your cache should not have to be loaded again.
This issue is severe, confirmed and demands immediate attention.
]
|
|
made changes - 14/Jan/09 02:47 PM
|
Comment
|
[ That's the problem with having people who are emotionally involved with the issue setting priority. Everyone thinks the issues that effect them are all showstoppers. This just doesn't fit the priority of showstopper and as quoted above and as the definition says if in doubt use critical. This is definitely a critical issue but detach you're emotions for one second if you can to try to evaluate whether this really fits the criteria. It doesn't. It should be noted that a Linden even changed it down from showstopper earlier which should be a good indicator.
Incidentally they in all my times here have only once to my knowledge punished someone for abuse of priority and that was for someone flagrantly spamming new showstopper issues just to grief the JIRA. If you're doing it in good faith which I think everyone here is then the most that ever happens is a Linden steps in and asks you to stop changing the priority so often since it's spamming their inbox.
]
|
|
made changes - 14/Jan/09 02:48 PM
|
Comment
|
[ @Gordon,
If SL is a game platform, I agree with you (and LL, apparently) that this is a critical issue, not a showstopper.
If SL is to be taken seriously as a viable business platform, this is absolutely a showstopper issue.
Agree or disagree with LL's opinion in the matter, LL defines SL as either a game or a viable business platform when it makes these types of prioritization decisions. It's that simple. No emotion. No drama.
-DK
]
|
|
made changes - 14/Jan/09 02:48 PM
|
Comment
|
[ I think the actual priority doesn't really matter in this phase. Either LL knows exactly what's going on and are really working to fix these issues, or the amazing world of Second Life will be deserted as soon as any serious competetor shows it's face. Since at least the beginning of august the residents of SL are living with these slow texture issues all the time. We're talking half a year here. Seeing we're frequently at maximum logins, I guess we can afford losing the thousands of people who left and the ones not even starting because "it's SO slow.."
I guess the worst part are the HUGE continuous data transfers.
]
|
|
made changes - 14/Jan/09 02:49 PM
|
Comment
|
[ Personally I think LL is going to have to retract jira user rights on the core issue portion (description, priority, etc.) to put a stop to people treating the jira as a forum. That would eliminate a lot of grief. Linden Lab can adjust the data after triage themselves since they are the only shepherds in this enterprise.
Going back on topic:
As for this and other texture related jira issues I doubt Linden Lab will do anything about these texture performance jira entries until after they/we see what the overall effect of the conversion to http protocol is anyway. That code needs to go in and then see what all still needs to be fixed.
]
|
|
made changes - 14/Jan/09 02:49 PM
|
Comment
|
[ why should this be Priority Critical?
Can not do the following in SL:
Can't shop, can't join contests, can't see av's, can't build, can't RP, Can't do much of anything all because textures won't load, or are taking hours to load.
this effects almost EVERYONE in sl.
Some have left SL because of this.
these texture problems have been going on for considerable time.
These problems get worse with every update.
THIS is why it is a showstopper.
"Showstopper mean that you many others are unable to login or use the world"
Fact: 200 textures loading at 20 seconds or more each requires OVER AN HOUR. What part of "unable to use the world" doesn't apply there?
Wayfinder wrote:
(wayfinder wishbringer added a comment - 16/Sep/08 09:50 PM - edited
And BTW, to respectfully question Linden Lab's attitude toward this issue... I still question Dan why you don't believe this is a showstopper issue. What do you call an issue that costs Linden Lab customers on a daily basis.. and that negatively affects EVERY SINGLE USER on Second Life every single day? If that's not a showstopper... what IS a showstopper exactly? The entire grid crashing due to California sinking into the ocean? The U.S. government taking over Second Life and turning it over to Congress? A hurricane in San Francisco? How serious does something have to be before LL considers it showtopper status? ; )
Fact: slow texture loading (and "slow" is an understatement) on Second Life negatively impacts every customer on the grid on a daily basis and regularly causes people to leave Second Life in frustration.
So how is this issue not a showstopper?
Please Define Showstopper.
]
|
|
made changes - 14/Jan/09 02:50 PM
|
Comment
|
[ Shango, it's critical because although you're thinking emotionally instead of logically and think that this issue getting fix is the difference between SL being a nice happy dream world for you and the end of SL as you know it the issue does not fit the criteria for showstopper as logically laid out in the guidelines on what constitutes a showstopper issue. That's why it's a critical issue and not a showstopper issue.
]
|
|
made changes - 14/Jan/09 02:50 PM
|
Comment
|
[ Your wrong please read my post again it has been edited. it was being edited when you responded.
Jira servers are responding a bit slow right now.
when I use jira i do NOT think with my emotions, please do not assume such.
Please give me the definition of Showstopper.
]
|
|
made changes - 14/Jan/09 02:51 PM
|
Comment
|
[ Please note the number of people experiencing this problem is much much higher then what is being reported here.
most of the people experiencing these problems do not bother to report to jira.
]
|
|
made changes - 14/Jan/09 02:51 PM
|
Comment
|
[ /me sighs
the definitions are slightly too broad, kinda overlapping with each other and uses somewhat subjective values here and there, it's kinda understandable that there isn't an agreement, I remember them being a bit clearer than that...I guess ideally we would need to have a good talk with a Linden about how exactly to choose the priority for this issue, but that is probably never gonna happen I guess...I initially came here to post a comment on how to stop the editwar about the priority of this issue, but as I actually started writing the comment here I realized I didn't really had an argument as good as really thought I had...sorry for wastin your time... U.U
]
|
|
made changes - 14/Jan/09 02:52 PM
|
Comment
|
[ Tigro, I'd never accuse you of wasting our time :)
Shango, here is the definition as requested although it was already posted a bunch of comments up as well.
Showstopper - ONLY the most severe, *confirmed* issues which demand immediate attention from Linden Lab. For example, inability for many Residents to login. IMPORTANT: Abusing this setting will cause revocation of Issue Tracker access. If in doubt, mark "Critical" instead.
]
|
|
made changes - 14/Jan/09 02:52 PM
|
Comment
|
[ This pissing contest over the 'priority' of this issue is accomplishing nothing but filling up our email inboxes. At this point, it's not going making a lick of difference to the Linden's approach to resolving this issue -- they're well aware of it (see the forums, and above). It's apparently not as easy to fix as some of the self-styled software-and-database-and-network experts here seem to believe. (There's nothing easier than a job someone else has to do.)
If you want to accomplish something other than huffing and puffing, _please_ scroll up to Dan Linden's request for specific diagnostics and see if you can contribute data toward the eventual solutions.
]
|
|
made changes - 14/Jan/09 02:53 PM
|
Comment
|
[ Just a note on you're post of 1:54pm, I'm really loathe to look it up because it would take a lot of digging but the Lindens have said quite a few times that they don't take priority very seriously specifically because of situations like this where people stubbonly insist that issues are higher priority than they really are so they go by votes and other indicators instead.
]
|
|
made changes - 14/Jan/09 02:53 PM
|
Comment
|
[ Iatransa, the whole texture stalling thing does seem like a legitimate issue but half of the comments don't seem to be about that and just seem to be general complaints about how SL is loading slowly for them and the perceived loss of performance after each update which may very well be influenced by the fact that "everyone else is experiencing it so I must be experiencing it to" syndrome.
Again that isn't to minimize the texture stalling issue but the fact that this has become a catch-all for complaints about rez speed somewhat drowns out the legitimate posts about the real issue or rather bug.
]
|
|
made changes - 14/Jan/09 02:54 PM
|
Comment
|
[ LL can NOT go by votes. it has been said MANY times.
I'll say it again because people don't seem to UNDERSTAND nor does LL seem to care to UNDERSTAND, That the number of people who vote on these issues does NOT I repeat DOES NOT represent the true number of people who are experiencing this and many other issues reported in jira.
There are over 65.000 logged into SL during peak hours. of the 65,000 residents logged in, MOST are having textures rezzing issues. MOST.
Of the 65.000 residents only 234 vote on this issue Alone. That's a very small number of people who actually use jira.
From what I understand MOST the SL residents don't bother to use jira when encountering issues like this.
Therefor LL can NOT go by votes alone.
The Number of people who vote on these issues, do NOT, and can NOT, accurately represent the TRUE number of people experiencing this issue.
]
|
|
made changes - 14/Jan/09 02:54 PM
|
Comment
|
[ @Gordon, please don't tax other contributors with being emotional. First, it's a personal attack that is contrary to the JIRA TOU. Second, it just leads your target to answer in the same tone, third it raises the emotional heat all round. Criticise people's arguments, not the people themselves.
I do not accept your argument that only a confirmed issue can have showstopepr status, not because I disagree with LL's guidelines but because you're misreading them. The obvious question is confirmed by who and by what method. The guidelines are silent. I take it you read them to 'confirmed' to mean 'confirmed by the Lindens' even though that is not what the guidelines say.
Dan Linden has noted that LL cannot repro this condition n their own network because they do not have the resources to test under end user conditions. The way they test under end user conditions is inputs from users. By that standard this issue has been repeatedly confirmed on this thread by screen shots and tech specs using different hardware and the methods suggested by WorkingOnIt Linden.
Clearly the Lindens take this issue seriously. If a Linden chooses to downgrade it then that's their policy for them to enforce. You chose to downgrade the issue contrary to the consensus of the thread and on a reading of the guidelines which (1) would have the effect of ensuring that there could never be a showstopepr issue and (2) would deprive the Lindens of inputs they have again and again said they consider extremely valuable.
I think the issue should be upgraded to its correct priority of showstopper but I am not prepared to get into a foodfight to achieve that. Downgrading the priority does nothing to reduce the urgency of the Lindens fixing this bug chain.
]
|
|
made changes - 14/Jan/09 02:54 PM
|
Comment
|
[ Gordan have you actually read any of the posts made to this issue since it's first reported?
Most the posts I'v read and I'v read every single one here, MOST relate to this texture issue.
yes there are a few slightly off topic posts, but gain they relate to the main issue here. all information posts here is important.
]
|
|
made changes - 14/Jan/09 02:56 PM
|
Comment
|
[ Shango, unfortunately they don't tell us exactly what if anything they necessarily go by other than occasional bits and pieces and each Linden seems to do things different.y That being said I don't think they go by votes alone but since they always seem to emphasize getting people to vote on impiortant issues to you and vote on the issue if it effects you it seems like the "popular" feature requests and issues get overreported in votes and a lot of important issues get under reported as was said because most people never use or even know about the JIRA.
]
|
|
made changes - 14/Jan/09 02:56 PM
|
Comment
|
[ Shango, I never mentioned confirmed, the only time I used it was when quoting the JIRA definition although since you bring it up I think a solid confirmation and repro by a user is just as valuable as one by a Linden since when it comes to debugging and resolving an issue it doesn't matter who's posting the steps. On the topic of it being the Linden's responsibility to keep it downgraded yes that's true since it's their JIRA but by that same logic it's up to the Lindens to upgrade the issue if it it needs to be upgraded to showstopper and if as you say the Lindens are aware of this issue then it would have been upgraded by now if needed.
]
|
|
made changes - 14/Jan/09 02:56 PM
|
Comment
|
[ Returned to "Showstopper" because the issue prevents many users from accessing Second Life due to the rapid, unnecessary consumption of Bandwidth, and due to frustration with textures taking excessively long to resolve.
]
|
|
made changes - 14/Jan/09 02:57 PM
|
Comment
|
[ Shango, yes I have and with a small exception of posts about texture hanging or the ones with the technical info to help find a common cause/solution most fo these are incredibly subjective. The fact that the issue itself is phrased subjectively as "worse since last version" doesn't help. Correct me if I'm wrong but a bug should outline an issue that you're having, the systems information, and if needed steps to reproduce, you have the last two in spades from a lot of the commenters but other than the stall issue (which should really be it's own bug I think) there's no clear issue here just subjective statements comparing it to older versions.
]
|
|
made changes - 14/Jan/09 02:57 PM
|
Comment
|
[ Incidentally a comment on the changes, so I'm not accused of griefing I'm only changing it as I make comments to back up why I believe it should be changed or in a few cases when it was changed while I was writing a post. Although other people have commented agreeing with me on the priority since I'm the only one who seems to be changing it to follow Dan Linden's change and JIRA policy I don't want to give anyone a reason to accuse me of griefing or anything.
]
|
|
made changes - 14/Jan/09 02:58 PM
|
Comment
|
[ Gordan if you actually scrolled up to post 1 and read down from there you would realize this has been Solidly CONFIRMED and Reprod. by MANY residents here. And that this issue MEETS the criteria of showstopper.
Please leave the setting alone and let the LIndens alone make the final call on this.
And Gordan if we don't stop this Priority setting war both of us are going to get banned from Jira. Leave it be.
]
|
|
made changes - 14/Jan/09 02:59 PM
|
Comment
|
[ Shango, As I said earlier I'd argue that neither of us are abusing the JIRA although I think the preferred method is that we talk it out rather than changing it at each comment. On the topic of priority this is the priority set by a Linden and it is the priority that arguably best fits the definitions given as has been confirmed by multiple other residents. Say I'm misinterpreting the definitions if you will, it wouldn't be the first time, but I don't see how you can claim that Showstopper is the right priority when a Linden has stated that this should be a critical rated issue and quite a few other residents agree that showstopper's narrow definition doesn't fit here. So I'm sorry, you say leave it alone until a Linden intervenes I'll say the same thing, get Dan to change his statement that this should be critical or I don't see why his priority rating shouldn't be enforced.
]
|
|
made changes - 14/Jan/09 03:00 PM
|
Comment
|
[ I changed the tittle a bit (or perhaps more than that), there is already a field to specify which versions are affected, and details like comparing with how things were before the issue was present I think probably should go on the description of the issue and/or comments
if you think I shouldn't have done this modification, feel free to change it back, but please explain your motives
]
|
|
made changes - 14/Jan/09 03:01 PM
|
Comment
|
[ /me sighs
you undid the change I had made to the title without even trying to convince anyone the change I made was wrong...
]
|
|
made changes - 14/Jan/09 03:02 PM
|
Comment
|
[ George; screw off. This is a reproducable bug that is stopping or hindering people from using Second Life; i.e. a Showstopper.
I'm reporting you for fraudulent error reporting.
]
|
|
made changes - 14/Jan/09 03:03 PM
|
Comment
|
[ I see you not the kind of person that can leave it alone, or be reasonable.
And many people have confirmed this should be a show stopper, in fact if you have in fact READ ALL the posts made here since post #1 you would see most agreed it was show stopper. I don't recall most agreeing it to be Critical.
Why are you being so dam stubborn?
]
|
|
made changes - 14/Jan/09 03:03 PM
|
Comment
|
[ Gordon
If the status quo is to prevail until action by a Linden then the status quo is the situation before you launched this classification food fight.
It is true a Linden classified it as critical. It is also true that was weeks ago and the Lindens have given their silent consent to showstopper priority by leaving it that way since then, even though several Lindens have commented in the interim.. You're claiming to apply a guideline that only exists if 'confirmed' means 'confirmed by the Lindens'. You offer no logical reasons for adding those words. The bug has been confirmed dozens of times by extremely detailed bug reports. Unilaterally amending the guidelines, which is what you're doing, and then claiming that you can act to impose your guideline but no-one else has the same right is not showing a bright line of logic. Neither is dismissing anyone who disagrees with you as 'emotional' or 'subjective'.
]
|
|
made changes - 14/Jan/09 03:04 PM
|
Comment
|
[ An examination of George Wendt's practices on the JIRA show that he has a tendency to try to impose his own often mistaken opinions on JIRA issues, regardless of any logic or reasonable argument against him.
It's best to just ignore him, and edit the issue to put it back at it's proper priority any time he tries to drop it. Eventually, the Lindens will ban him for fraudulent issue reporting.
]
|
|
made changes - 14/Jan/09 03:04 PM
|
Comment
|
[ wow, it suddenly changed from being a difference of opinion but a good discussion to being hostile and with personal, insults thrown in to boot.
I'm sure there are plenty of people who say that this is showstopper but that doesn't make that right just like the fact that I don't think it's a showstopper doesn't make me right. The fact that a Linden says it's not a showstopper makes me right.
If you want a good example incidentally of why letting a majority of angry emotional people set a technical flag on an issue is a bad idea take a look at the MISC-1776 where a majority of residents trying to incorrectly use a technical tool (the JIRA) to badger LL think that a price change is a showstopper. That may not seem like a great example but it fits perfectly into my statement earlier that everyone thinks that their little pet issue deserves to be the first one looked at and the first one changed and use showstopper to do so.
]
|
|
made changes - 14/Jan/09 03:04 PM
|
Comment
|
[ Can you at least spell my name right, it's Gordon G-O-R-D-O-N
]
|
|
made changes - 14/Jan/09 03:05 PM
|
Comment
|
[ Just because he's a linden, it doesn't mean he's right. He's part of the problem, so his view of the issue is irrelevant to what actual users are experiencing.
Stop sabotaging this JIRA, George
]
|
|
made changes - 14/Jan/09 03:05 PM
|
Comment
|
[ This is a serious issue and the childish acts of these comments are making this less than what it is. Will you guys just grow up and act like adults? Im sick of getting your foolish emails!
]
|
|
made changes - 14/Jan/09 03:05 PM
|
Comment
|
[ Showstopper - ONLY the most severe, *confirmed* issues which demand immediate attention from Linden Lab. For example, inability for many Residents to login. IMPORTANT: Abusing this setting will cause revocation of Issue Tracker access. If in doubt, mark "Critical" instead.
Ok lets go over this logically again bit by bit
-ONLY the most severe, *confirmed* issues which demand immediate attention from Linden Lab
------ Is this severe yes, it effects many residents and as I said many times despite many people mis-stating me it doesn't matter who can confirm it as long as it's confirmed
-For example, inability for many Residents to login.
--------------Ok, not everything is going to fit that example but this is not even close to that, is you're use of SL severely hampered, yes but you can login, you can instant message, you can chat, you can complete transactions and commerce although that's hindered by slow graphic rendering
IMPORTANT: Abusing this setting will cause revocation of Issue Tracker access.
-------------Until people started hurling personal insult I don't think that was ever an issue, we had a disagreement on how an issue should be prioritized and we debated back and forth on the merits of why it should be a critical issue or a showstopper issue.
If in doubt, mark "Critical" instead.
-------------This is the key point, if it was just my doubt then that's one thing but quite a few people have stated that this should be a critical issue rather than a showstopper issue so I think at least until Dan can be asked to weigh in again this should stay a critical issue.
]
|
|
made changes - 14/Jan/09 03:06 PM
|
Comment
|
[ Just incidentally it is very hypocritical that the same people criticizing me by saying that I'm sabotaging an issue by lowering it's priority are some of the same people who said that priority isn't the issue and priority doesn't matter because the Lindens already have this on their radar. Fine, if priority doesn't matter then lets leave this as critical until Dan weighs in on it, I'm sure someone's already emailed him to look at this (and probably asking to have me banned from the JIRA) and let it rest for the night.
Someoen will probably ask why don't I just leave it at showstopper and ask Dan to look at lowering it. I have no better answer to that then you probably do for keeping it showstopper but I'm willing to admit I'm being somewhat hypocritical with the defense that it is my belief that having an issue wrongly set to too high of a priority does a greater harm than having it set to a lower priority until it can be properly prioritized whether that be it being left the same or bumped up. And I stand behind my statements that :'OMG I CAN'T SEE TEXTURES IN SL" counts as an emotional response to a technical issue and clouds the issue.
]
|
|
made changes - 14/Jan/09 03:06 PM
|
Comment
|
[ Gordon, it *is* a severe, CONFIRMED issue; it's been confirmed by multiple reporters. Stop messing with this JIRA. Face it, you're wrong.
]
|
|
made changes - 14/Jan/09 03:07 PM
|
Comment
|
[ Ann, no more than any of these other people. I made a change and backed it up with fact as to why I thought the issue was wrongly prioritized. Someone disagreed and changed it back. The proper thing to do would probably have not been to change it back (you'll notice I'm not changing it right now) but just to comment as to why I thought it was wrong however up until the last 10 comments or so the back and forth was if not friendly then professional each of us giving reasons why we thought the other was wrong. Again, we were both wrong to keep changing the issue. Other people came in and came their views some supporting critical many supporting showstopper. Some more people came in and started getting hostile and it's essentially gone downhill from there. Please show where there has been griefing since I fail to see it. Other than admittedly making the mistake of changing the issue priority each time rather than just commenting which not just I did I don't see any griefing anywhere.
Incidentally, here is the email I sent to Dan asking for his input not just on the priority but also n what is being done in terms of fixing it.
Dan, could you please take a look at VWR-8503 on the pjira? despite you're lowering the priority to critical it was re-raised back to showstopper which I felt was wrong. An edit war has been ensuing since so I was hoping you could look at it and chime in on A) the proper priority and B) what if anything LL is doing in terms of working on this since I'm sure that's one of the reasons people are frustrated about this.
Thanks.
-Gordon Wendt
]
|
|
made changes - 14/Jan/09 03:07 PM
|
Comment
|
[ As someone (sorry comments are taking forever to load right now so I can't grab your name) said before, this has happened before and you'll see that I do get caught up in it and do get into revert wars however when I do stop long enough to realize it each time I do stop reverting and work towards an amiable solution such as I am doing now.
]
|
|
made changes - 14/Jan/09 03:07 PM
|
Comment
|
[ G-O-R-D-O-N,
That fact that textures are NOT REZZING seriously hampers the ability to USE SL for MOST Residents..
MOST transactions require the Textures on the vendors and ATM's to be FULLY rezzed, read in order to READ them.
This issue is Sriosly hampering peoples ability to play/use SL
This issue is preventing/hampering people from doing the following: shopping, completing builds, Transactions requiering a fully rezzed vendor/ ATM, texturs and all, RPing in RP sims such as the SL Fire Department RP fire, RP combat, RP policing incidents, ect., flying planes, boating, driving, biking. SL is grey most the time, Evan the orientation islands are useless with no textures rezzing.
THIS is why it's a showstopper it is next to impossible to do anything BUT chat in a grey SL.
And the Jira issue you linked us to? bad example pal. people are in there every rights to be angry and emotional about the open sim issue.
]
|
|
made changes - 14/Jan/09 03:08 PM
|
Comment
|
[ for reference I believe he is dan@lindenlab.com but in case I'm wrong I'll also IM him and encourge everyone else to not rely on that email being right since Lindens' emails don't always follow the same forumula (torley@lindenlab.com vs robla@lindenlab.com for example).
]
|
|
made changes - 14/Jan/09 03:08 PM
|
Comment
|
[ LEAVE THIS ALONE GORDON.
]
|
|
made changes - 14/Jan/09 03:09 PM
made changes - 14/Jan/09 03:09 PM
|
Comment
|
[ I don't understand...I don't think you could put that many rutabegas into a lama, even if you did hollow it out first.
regards
SemiHolyGhost Ferlinghetti
]
|
|
made changes - 14/Jan/09 03:55 PM
|
Comment
|
[ Shango, notice I have not changed the priority in the last 4 comments I made so I'm trying to be considerate here by stopping the revert warring since that's not getting anywhere and is just making everyone hostile.
Shango, yes they do have every right but it proves my point that angry and emotional people do not necessarily make good decisions. My point was that if you took that issue and ran it against the definition of showstopper it would fall majorly short. That was my point.
]
|
|
made changes - 14/Jan/09 03:55 PM
|
Comment
|
[ Odds of any value in debugging obsolete code before http protocol is rolled out:: Zero
Dan is working on this problem but seriously there is nothing anyone can or should do beyond giving the http protocol rollout a severe pounding to flush out any defects with it. Only then will we know if there are any additional defects, siuch as possible caching issues, remaining in the code.
Argue all you want but there is an order of progression that must be followed in this area of the code because a major framework change is on the way in.
Prepare your test cases for the http protocol rollout.
]
|
|
made changes - 14/Jan/09 03:55 PM
|
Comment
|
[ I recommend everyone watching or visiting this JIRA to report Gordon Wendt for abuse of the JIRA report system; insisting on imposing his own flawed view on something that multiple responders have agreed is a Showstopper Issue. Also, if you see the priority dropped to Critical again, sign in, and click EDIT to switch the priority back to what it should be. One loser with too much time on his hands isn't going to put a dent in our determination to get the Lindens to address this issue NOW.
]
|
|
made changes - 14/Jan/09 03:56 PM
|
Comment
|
[ My thanks to everyone who has helped to identify the actual problems addressed here. I am still not able to do as much in SL as I would like. The new RC has helped a bit. I am sorry it has degenerated into personal attacks, and petty power plays.
I look forward to the day when I can use SL again.
]
|
|
made changes - 14/Jan/09 03:56 PM
|
Comment
|
[ I'm sorry if you haven't seen results from abuse reports, Khyota, but I have.
]
|
|
made changes - 14/Jan/09 03:56 PM
|
Comment
|
[ Khyota; the Lindens don't care how many votes something has. Some very trivial things have a lot of votes, because one group or another wants a specific feature or fix for their own desires. Issues like that can get a lot of votes, but be meaningless to what needs to be dealt with in SL. It's only issues that both have a lot of votes, and are rated Showstopper that have a chance of getting their attention. So, Gordon Wendt was actually sabotaging our attempts to get this dealt with by dropping it below the Lindens' radar, so to speak.
]
|
|
made changes - 14/Jan/09 03:56 PM
|
Comment
|
[ I say this because there is very real evidence that the Lindens are being very dishonest with us. They have ignored this issue for 3 years, but the only method we have of trying to convince them to deal with it is to jump through their hoops. That means keeping his issue very much alive and active; and set at Showstopper.
The Lindens are already using us as unpaid beta-testers for their system; the very least they can do is concern themselves with what we tell them needs to be fixed, and take into account our recommendations. Yet, they don't do that. They make us jump through hoops over and over. People have given them the data they asked for, and all we get as results are people randomly setting the issues "Resolved: Unreproducable" or "Resolved: Needs more info"; both indicating that they didn't take any time at all to actually try to observe the problem from a user's perspective
All we can do is keep this issue a hot topic for them, putting whatever pressure we can, given this limited vehicle. Chastising people for doing so is counterproductive for getting this dealt with.
]
|
|
made changes - 14/Jan/09 03:57 PM
|
Comment
|
[ chalice said: "What, seriously, more do you want, than them to work on it? "
Actually, there is one more thing I'd like.
We PJIRA users -- a fair number of us anyway -- pour a lot of effort into documenting our experiences and observations with Linden products here. But the actual discussions and some very important information about the problem determination and bug fixing process never finds it's way back out here, because it's being tracked on the internal JIRA at Ll that only their people have access to.
I've been a user (and sometimes a designer and implmenter) of issue tracking systems for more decades than I care to think about, and I know you can't expose everything that goes on doing this work to your clients.
But I gotta say, the more the LL devs can tell us about what they are thinking, suspecting, planning or changing in the code, the strategies they're applying, and the strengths and weaknesses of those strategies, the better job we can tell them about what's *actually* going on out in what we laughingly call the real world, aka Agni.
ESR is famous for saying something like "to many eyeballs, all bugs are shallow". There's a lot of eyeballs on the grid, and some of them are pretty sharp cookies.
I know what a pain it is to update dual tracking systems. I've been there. But one very important reason that you see people screaming and yelling and showstoppering JIRAs is that too often there's little or no indication that anybody behind the wall at LL hears us. Few people have the ability to camp out in office hours...and that's probably a good thing. But it would be really great if the volume flow of information back out to PJIRA was a bit more like the volume of the flow of information in.
I wonder if a small javascript bookmarklet that copies a comment from the internal JIRA to PJIRA might be helpful? I know we really, really, really don't want to do that with every internal comment, but I bet there's a lot of comments that would deeply benefit from being easily fed back to those of us on the other side of the wall.
]
|
|
made changes - 14/Jan/09 03:57 PM
|
Comment
|
[ @Georgie Greggan: So, we've got some mob-style legbreaking going on, to punish the whistle-blower, hm?
]
|
|
made changes - 14/Jan/09 03:58 PM
|
Comment
|
[ Logins disabled, I can't log in:
"Due to higher than usual load, logins have been temporarily disabled."
Around 71,000 residents currently on line.
It looks like the DDOS texture thrashing is starting to bite. Clearly it would be to everyone's interest if this texture problem was fixed sooner rather than at the usual 9 to 5 pace of the devs.
Iexo Bethune commented on VWR-8503:
-----------------------------------
@Georgie Greggan: So, we've got some mob-style legbreaking going on, to punish the whistle-blower, hm?
Unfortunately (or naturally), this issue is causing a lot of heat and emotion. Can there be a quick fix? Doubtful. So there will continue to be some anger expressed. But anger does not fix the problem. I do hope the Lindens are careful about shooting the messenger when the messenger has a lot to contribute.
]
|
|
made changes - 14/Jan/09 09:30 PM
|
Component/s
|
|
Graphics
[ 10023
]
|
|
Component/s
|
|
Performance
[ 10025
]
|
|
Description
|
*Bug:* Textures are loading so incredibly molasses slow that it's seriously detrimental to the SL experience.
I almost listed this as a "showstopper" due to the extremely negative effect on SL. Similar reports have been issued before, but 1.20 brings this problem to an all-new level.
I'm going to repeat a thought that has been stated repeatedly over the last year: When a person is in a sim for a lengthy period of time and all textures have already loaded, the fact that a new texture takes up to 30 seconds, a minute or even longer to load indicates an extremely borked texture loading process. No individual texture should take more than one second to load under any circumstance.
{panel:title=Extended Discussion is in the SL Forums| borderStyle=dashed| borderColor=#ccc| titleBGColor=#F7D6C1| bgColor=#FFFFCE}
Linden Lab recognizes there are ongoing passionate reports, frustrations, and resident-to-resident suggestions on this issue. These type of discussion comments have been moved to a SL Forum thread :
http://forums.secondlife.com/showthread.php?t=302416
The Issue tracked here is intended for active investigation of the problem. Comments below on this bug are to share technical details which may help Linden Lab to isolate the bug to be fixed.
*For off-topic posts, comments, or resident-to-resident discussion & support, please use the Forum link above.* Comments below which are off-topic may be deleted.
{panel}
*Examples:*
* I attended a fireworks show the other day. Textures were loading so slowly the fireworks displays all looked like gray boxes.
* Went shopping at a fast sim. Vendor textures were loading so slowly I finally got tired and stopped shopping for the day.
* I have a particle poofer. Triggered it. The SINGLE texture had barealy loaded by the time the poofer finished (10 seconds later). So I figured if I set it off again the texture would show up immediately. Nope, same response. It was as if the system had dumped the texture that it had just loaded and it went through that process all over again. That has not been the case in earlier versions of SL.
* I rezzed into an area. Green dots show avatars all over the place.. .but those avatars can take up to ten minutes to even appear on the screen in any form.
* I have a sculpty-texture avatar. Probably contains 25 different sculpty shapes. That is 25 textures. I would grant that maybe that avatar is going to take 30 seconds to a minute to fully rez. Nope... TEN minutes. Makes the avatar totally useless to me (why wear an avatar people can't even see rezzed for ten minutes?).
*Further comments:*
From one systems analyst to another, I would strongly encourage LInden Lab to totally reconsider how they handle texture management. IMO it would seem the entire texture display system needs redesigned from the ground up... starting with the concept that (and forgive the caps.. they are to stress the concept: IF A USER CLICKS ON AN OBJECT (such a a vendor), LOAD THAT OBJECT'S TEXTURES NOW.
It seriously should never take more than one second for any individual texture to load... especially considering that SL stores textures in extremely compressed format. Even a second is excessive; if a sim has 1,000 textures, if each of those textures took a full second to load, the entire sim would take 17 minutes to rez. 2,000 textures would take more than half an hour. That's unacceptable performance.
I might suggest that when a person first enters a sim, texture loading should be given top priority, starting with avatars. And for sure, when someone is shopping an touches a vendor or clicks to the next item, that texture should load NOW. Otherwise shoppers get tired and frustrated and walk off.
|
*Bug:* Textures are loading so incredibly molasses slow that it's seriously detrimental to the SL experience.
I almost listed this as a "showstopper" due to the extremely negative effect on SL. Similar reports have been issued before, but 1.20 brings this problem to an all-new level.
I'm going to repeat a thought that has been stated repeatedly over the last year: When a person is in a sim for a lengthy period of time and all textures have already loaded, the fact that a new texture takes up to 30 seconds, a minute or even longer to load indicates an extremely borked texture loading process. No individual texture should take more than one second to load under any circumstance.
{panel:title=Extended Discussion is in the SL Forums| borderStyle=dashed| borderColor=#ccc| titleBGColor=#F7D6C1| bgColor=#FFFFCE}
Linden Lab recognizes there are ongoing passionate reports, frustrations, and resident-to-resident suggestions on this issue. These type of discussion comments have been moved to a SL Forum thread :
http://forums.secondlife.com/showthread.php?t=302416
The Issue tracked here is intended for active investigation of the problem. Comments below on this bug are to share technical details which may help Linden Lab to isolate the bug to be fixed.
*For off-topic posts, comments, or resident-to-resident discussion & support, please use the Forum link above.* Comments below which are off-topic may be deleted.
{panel}
_Added by Celierra Darling_: This issue appears to be a compounding of several problems with different causes, and has been made into a meta-issue (a group of smaller issues) to help organize the efforts to fix it. If you'd like to help tackle these problems, see linked issues above and the comment by Dan Linden here: [#action_94327] .
*Examples:*
* I attended a fireworks show the other day. Textures were loading so slowly the fireworks displays all looked like gray boxes.
* Went shopping at a fast sim. Vendor textures were loading so slowly I finally got tired and stopped shopping for the day.
* I have a particle poofer. Triggered it. The SINGLE texture had barealy loaded by the time the poofer finished (10 seconds later). So I figured if I set it off again the texture would show up immediately. Nope, same response. It was as if the system had dumped the texture that it had just loaded and it went through that process all over again. That has not been the case in earlier versions of SL.
* I rezzed into an area. Green dots show avatars all over the place.. .but those avatars can take up to ten minutes to even appear on the screen in any form.
* I have a sculpty-texture avatar. Probably contains 25 different sculpty shapes. That is 25 textures. I would grant that maybe that avatar is going to take 30 seconds to a minute to fully rez. Nope... TEN minutes. Makes the avatar totally useless to me (why wear an avatar people can't even see rezzed for ten minutes?).
*Further comments:*
From one systems analyst to another, I would strongly encourage LInden Lab to totally reconsider how they handle texture management. IMO it would seem the entire texture display system needs redesigned from the ground up... starting with the concept that (and forgive the caps.. they are to stress the concept: IF A USER CLICKS ON AN OBJECT (such a a vendor), LOAD THAT OBJECT'S TEXTURES NOW.
It seriously should never take more than one second for any individual texture to load... especially considering that SL stores textures in extremely compressed format. Even a second is excessive; if a sim has 1,000 textures, if each of those textures took a full second to load, the entire sim would take 17 minutes to rez. 2,000 textures would take more than half an hour. That's unacceptable performance.
I might suggest that when a person first enters a sim, texture loading should be given top priority, starting with avatars. And for sure, when someone is shopping an touches a vendor or clicks to the next item, that texture should load NOW. Otherwise shoppers get tired and frustrated and walk off.
|
made changes - 14/Jan/09 09:33 PM
|
Link
|
|
This issue is original of duplicate VWR-11557
[ VWR-11557
]
|
made changes - 14/Jan/09 09:34 PM
|
Link
|
|
This issue is related to by VWR-11550
[ VWR-11550
]
|
made changes - 16/Jan/09 07:11 PM
|
Description
|
*Bug:* Textures are loading so incredibly molasses slow that it's seriously detrimental to the SL experience.
I almost listed this as a "showstopper" due to the extremely negative effect on SL. Similar reports have been issued before, but 1.20 brings this problem to an all-new level.
I'm going to repeat a thought that has been stated repeatedly over the last year: When a person is in a sim for a lengthy period of time and all textures have already loaded, the fact that a new texture takes up to 30 seconds, a minute or even longer to load indicates an extremely borked texture loading process. No individual texture should take more than one second to load under any circumstance.
{panel:title=Extended Discussion is in the SL Forums| borderStyle=dashed| borderColor=#ccc| titleBGColor=#F7D6C1| bgColor=#FFFFCE}
Linden Lab recognizes there are ongoing passionate reports, frustrations, and resident-to-resident suggestions on this issue. These type of discussion comments have been moved to a SL Forum thread :
http://forums.secondlife.com/showthread.php?t=302416
The Issue tracked here is intended for active investigation of the problem. Comments below on this bug are to share technical details which may help Linden Lab to isolate the bug to be fixed.
*For off-topic posts, comments, or resident-to-resident discussion & support, please use the Forum link above.* Comments below which are off-topic may be deleted.
{panel}
_Added by Celierra Darling_: This issue appears to be a compounding of several problems with different causes, and has been made into a meta-issue (a group of smaller issues) to help organize the efforts to fix it. If you'd like to help tackle these problems, see linked issues above and the comment by Dan Linden here: [#action_94327] .
*Examples:*
* I attended a fireworks show the other day. Textures were loading so slowly the fireworks displays all looked like gray boxes.
* Went shopping at a fast sim. Vendor textures were loading so slowly I finally got tired and stopped shopping for the day.
* I have a particle poofer. Triggered it. The SINGLE texture had barealy loaded by the time the poofer finished (10 seconds later). So I figured if I set it off again the texture would show up immediately. Nope, same response. It was as if the system had dumped the texture that it had just loaded and it went through that process all over again. That has not been the case in earlier versions of SL.
* I rezzed into an area. Green dots show avatars all over the place.. .but those avatars can take up to ten minutes to even appear on the screen in any form.
* I have a sculpty-texture avatar. Probably contains 25 different sculpty shapes. That is 25 textures. I would grant that maybe that avatar is going to take 30 seconds to a minute to fully rez. Nope... TEN minutes. Makes the avatar totally useless to me (why wear an avatar people can't even see rezzed for ten minutes?).
*Further comments:*
From one systems analyst to another, I would strongly encourage LInden Lab to totally reconsider how they handle texture management. IMO it would seem the entire texture display system needs redesigned from the ground up... starting with the concept that (and forgive the caps.. they are to stress the concept: IF A USER CLICKS ON AN OBJECT (such a a vendor), LOAD THAT OBJECT'S TEXTURES NOW.
It seriously should never take more than one second for any individual texture to load... especially considering that SL stores textures in extremely compressed format. Even a second is excessive; if a sim has 1,000 textures, if each of those textures took a full second to load, the entire sim would take 17 minutes to rez. 2,000 textures would take more than half an hour. That's unacceptable performance.
I might suggest that when a person first enters a sim, texture loading should be given top priority, starting with avatars. And for sure, when someone is shopping an touches a vendor or clicks to the next item, that texture should load NOW. Otherwise shoppers get tired and frustrated and walk off.
|
*Bug:* Textures are loading so incredibly molasses slow that it's seriously detrimental to the SL experience.
I almost listed this as a "showstopper" due to the extremely negative effect on SL. Similar reports have been issued before, but 1.20 brings this problem to an all-new level.
I'm going to repeat a thought that has been stated repeatedly over the last year: When a person is in a sim for a lengthy period of time and all textures have already loaded, the fact that a new texture takes up to 30 seconds, a minute or even longer to load indicates an extremely borked texture loading process. No individual texture should take more than one second to load under any circumstance.
{panel:title=Extended Discussion is in the SL Forums| borderStyle=dashed| borderColor=#ccc| titleBGColor=#F7D6C1| bgColor=#FFFFCE}
Linden Lab recognizes there are ongoing passionate reports, frustrations, and resident-to-resident suggestions on this issue. These type of discussion comments have been moved to a SL Forum thread :
http://forums.secondlife.com/showthread.php?t=302416
The Issue tracked here is intended for active investigation of the problem. Comments below on this bug are to share technical details which may help Linden Lab to isolate the bug to be fixed.
*For off-topic posts, comments, or resident-to-resident discussion & support, please use the Forum link above.* Comments below which are off-topic may be deleted.
{panel}
(_Added by Celierra Darling_: This issue appears to be a compounding of several problems with different causes, and has been made into a meta-issue (a group of smaller issues) to help organize the efforts to fix it. If you'd like to help tackle these problems, see linked issues above and the comment by Dan Linden here: [#action_94327] .)
*Examples:*
* I attended a fireworks show the other day. Textures were loading so slowly the fireworks displays all looked like gray boxes.
* Went shopping at a fast sim. Vendor textures were loading so slowly I finally got tired and stopped shopping for the day.
* I have a particle poofer. Triggered it. The SINGLE texture had barealy loaded by the time the poofer finished (10 seconds later). So I figured if I set it off again the texture would show up immediately. Nope, same response. It was as if the system had dumped the texture that it had just loaded and it went through that process all over again. That has not been the case in earlier versions of SL.
* I rezzed into an area. Green dots show avatars all over the place.. .but those avatars can take up to ten minutes to even appear on the screen in any form.
* I have a sculpty-texture avatar. Probably contains 25 different sculpty shapes. That is 25 textures. I would grant that maybe that avatar is going to take 30 seconds to a minute to fully rez. Nope... TEN minutes. Makes the avatar totally useless to me (why wear an avatar people can't even see rezzed for ten minutes?).
*Further comments:*
From one systems analyst to another, I would strongly encourage LInden Lab to totally reconsider how they handle texture management. IMO it would seem the entire texture display system needs redesigned from the ground up... starting with the concept that (and forgive the caps.. they are to stress the concept: IF A USER CLICKS ON AN OBJECT (such a a vendor), LOAD THAT OBJECT'S TEXTURES NOW.
It seriously should never take more than one second for any individual texture to load... especially considering that SL stores textures in extremely compressed format. Even a second is excessive; if a sim has 1,000 textures, if each of those textures took a full second to load, the entire sim would take 17 minutes to rez. 2,000 textures would take more than half an hour. That's unacceptable performance.
I might suggest that when a person first enters a sim, texture loading should be given top priority, starting with avatars. And for sure, when someone is shopping an touches a vendor or clicks to the next item, that texture should load NOW. Otherwise shoppers get tired and frustrated and walk off.
|
made changes - 06/Feb/09 11:26 AM
|
Link
|
|
This issue is related to by VWR-11828
[ VWR-11828
]
|
made changes - 10/Feb/09 04:20 AM
|
Link
|
|
This issue is related to by VWR-11965
[ VWR-11965
]
|
made changes - 12/Feb/09 12:20 PM
|
Link
|
|
This issue is related to by VWR-12007
[ VWR-12007
]
|
made changes - 12/Feb/09 06:41 PM
|
Link
|
|
This issue is related to by VWR-12031
[ VWR-12031
]
|
made changes - 13/Feb/09 07:40 AM
made changes - 17/Feb/09 04:46 AM
|
Link
|
|
This issue is related to by VWR-12088
[ VWR-12088
]
|
made changes - 18/Feb/09 05:27 AM
|
Link
|
|
This issue Relates to VWR-5647
[ VWR-5647
]
|
made changes - 20/Feb/09 05:18 AM
made changes - 20/Feb/09 05:22 AM
made changes - 20/Feb/09 05:34 AM
made changes - 20/Feb/09 05:37 AM
made changes - 20/Feb/09 05:42 PM
made changes - 23/Feb/09 07:43 PM
|
Link
|
|
This issue is related to by VWR-12157
[ VWR-12157
]
|
made changes - 24/Feb/09 05:21 PM
|
Link
|
|
This issue is related to by VWR-12188
[ VWR-12188
]
|
made changes - 06/Mar/09 04:53 PM
|
Link
|
|
This issue is related to by VWR-12305
[ VWR-12305
]
|
made changes - 12/Mar/09 02:16 PM
|
Link
|
|
This issue is related to by VWR-12375
[ VWR-12375
]
|
made changes - 24/Apr/09 02:42 AM
|
Link
|
|
This issue is original of duplicate VWR-12933
[ VWR-12933
]
|
made changes - 27/Apr/09 02:37 PM
|
Link
|
|
This issue is related to by VWR-13019
[ VWR-13019
]
|
made changes - 27/Apr/09 03:05 PM
|
Link
|
This issue is original of duplicate VWR-12933
[ VWR-12933
]
|
|
made changes - 27/Apr/09 03:05 PM
|
Link
|
|
This issue is related to by VWR-12933
[ VWR-12933
]
|
made changes - 09/May/09 05:13 PM
made changes - 10/May/09 07:48 PM
|
Link
|
|
This issue is related to by VWR-13418
[ VWR-13418
]
|
made changes - 13/May/09 11:32 AM
|
Link
|
|
This issue is related to by VWR-13486
[ VWR-13486
]
|
made changes - 18/May/09 10:57 AM
|
Affects Version/s
|
|
1.23 Public Nightly
[ 10431
]
|
|
Affects Version/s
|
1.21
[ 10370
]
|
|
made changes - 18/May/09 11:59 AM
|
Link
|
|
This issue is related to by VWR-13421
[ VWR-13421
]
|
made changes - 17/Jun/09 08:29 PM
|
Affects Version/s
|
|
1.23
[ 10470
]
|
made changes - 20/Jun/09 12:20 PM
|
Summary
|
Meta-Issue: Textures loading worse in 1.21/1.22
|
Meta-Issue: Poor texture loading and freezes indicate larger chain of bugs
|
made changes - 22/Jun/09 08:41 AM
|
Link
|
|
This issue is original of duplicate VWR-12984
[ VWR-12984
]
|
made changes - 22/Jun/09 08:41 AM
|
Link
|
|
This issue is related to by VWR-12984
[ VWR-12984
]
|
made changes - 22/Jun/09 08:45 AM
|
Link
|
This issue is original of duplicate VWR-12984
[ VWR-12984
]
|
|
made changes - 22/Jun/09 08:52 AM
|
Meta Issue
Reopened
Showstopper
Meta-Issue: Poor texture loading and freezes indicate larger chain of bugs
