|
|
|
Second Life 1.23.1 (119104) May 4 2009 17:37:40 (Second Life Release Candidate)
Release Notes Built with GCC version 40001 You are at 241126.2, 282609.5, 22.8 in George 5 located at sim2839.agni.lindenlab.com (216.82.19.82:13001) CPU: Dual PowerPC 970 (2000 MHz) libcurl Version: libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 I faced south until everything rezzed then faced north for one minute turned back to south and took the snapshot Problem is the same with me, Region that i've been on for a hour and just zooming out the textures are downloaded again even though i have viewed them some time ago before turning my avatar round. Also getting a garbled texture info window as noticed on the pictures attached.
Second Life 1.23.1 (119104) May 4 2009 17:53:10 (Second Life Release Candidate) Built with MSVC version 1400 You are at 147214.3, 236826.4, 22.8 in Ciel located at sim8329.agni.lindenlab.com (216.82.38.142:13002) CPU: Intel Core 2 Series Processor (2400 MHz) libcurl Version: libcurl/7.18.1 OpenSSL/0.9.8j zlib/1.2.3 Adding "textures" in the summary to avoid more dups
Confirmed on Linux Ubuntu 9.04, and as a general feeling I'd say that after 10-15 minutes, most textures are discarded.
Reproduced and documented: Second Life 1.23.2 (2259) May 14 2009 16:06:24 (Second Life OSS) Built with GCC version 40102 Updated to reflect this happens on "http-texure" aka "oss build" viewer too.
See this often on MAC, especially in texture rich environments.
Second Life 1.22.8 (109366) Feb 1 2009 12:55:38 (Second Life Release Candidate) You are at 253713.7, 256271.0, 26.2 in Bay City - Rollers located at sim7310.agni.lindenlab.com (8.10.146.58:13000) CPU: Dual i386 (Unknown) (2400 MHz) Please note: I'm going to elevate this to "Showstopper" for the moment, and encourage a Linden to put it back to something like Major, but only after considering that this problem may overwhelm LL's internet bandwidth if this release goes GA like this. I observe this to be very substantially worse in 1.23 than with the 1.22 release, so unless there's something idiosyncratic about that, LL just won't be able to afford concurrency volume of viewers downloading all their textures over and over again. So I think this really is a showstopper for LL, albeit merely a major pain for users.
Attaching "turn90degreesafter5minutes.png"... from a sky build at 3200m, turning 90 degrees from one modestly textured view back to another, after just 5 minutes. Second Life 1.23.2 (120258) May 13 2009 18:53:50 (Second Life Public Nightly) Built with GCC version 40102 CPU: Intel(R) Pentium(R) D CPU 2.66GHz libcurl Version: libcurl/7.16.4 OpenSSL/0.9.7c zlib/1.2.3 c-ares/1.4.0 Agreeing with heading.
Second Life 1.23.1 (119104) May 4 2009 17:53:10 (Second Life Release Candidate) Built with MSVC version 1400 You are at 287030.8, 279761.1, 76.0 in Roclaren located at sim4837.agni.lindenlab.com (216.82.55.233:13002) CPU: Intel Core 2 Series Processor (2000 MHz) libcurl Version: libcurl/7.18.1 OpenSSL/0.9.8j zlib/1.2.3 Agree entirely with everything here. Textures are being dropped from the memory cache far too aggressively, including inventory folder icons, inventory item icons - but NOT, apparently, other UI elements. Simply standing in a moderately built-out sim, if you wait for everything to rez, then turn around - everything must decode & redraw. Turn back around, and the objects you were JUST looking at must RE-DECODE (the slowest part of the cache retrieval) and redraw. Not just a matter of grey textures, but completely rebuilding the prims even before the grey is applied.
This is yet another good reason separate the texture cache and the virtual cache, and store textures as GL textures (ready-to-use) rather than JPG2000 textures that have to be decoded again every read. Second Life 1.23.2 (120258) May 13 2009 19:37:00 (Second Life Public Nightly) Built with MSVC version 1400 You are at 262547.5, 255159.8, 104.6 in Honeoye located at sim4920.agni.lindenlab.com (216.82.27.131:13002) CPU: Intel Pentium 4 (Unknown model) (2992 MHz) libcurl Version: libcurl/7.18.1 OpenSSL/0.9.8j zlib/1.2.3 Is this behavior worse in 1.23 RC viewers than in the 1.22.11(release) viewer?
Dan: in my experience yes, totally.
I can't even reproduce this in the Linux 1.22.11(release) viewer, while it's easy to reproduce, and it's pretty tough, on both 1.23 RC1 and Snowglobe viewers. System specs as above. Two more screenshots of discarded/grey textures and texture console: Dan: totally. Enough to notice. Moreover textures take way more time to load.
Here are my specs : - Second Life 1.23.2 (120719) May 18 2009 12:02:26 (Developer) Built with GCC version 40102 169527.7, 271803.1, 26.0 in Shinobiya land located at sim5905.agni.lindenlab.com (216.82.51.207:13002) CPU: Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz libcurl Version: libcurl/7.16.4 OpenSSL/0.9.7c zlib/1.2.3 c-ares/1.4.0 Dan, I am also running 1.23.rc2 and see textures that are not active on screen but are very near having to be decoded again when I turn or move bringing them on screen again.
Second Life 1.23.2 (120719) May 18 2009 09:43:42 (Second Life Release Candidate) Built with MSVC version 1400 You are at 300880.2, 280906.1, 30.6 in Eyharts located at sim8325.agni.lindenlab.com (216.82.38.138:13001) CPU: Intel Core 2 Series Processor (2400 MHz) libcurl Version: libcurl/7.18.1 OpenSSL/0.9.8j zlib/1.2.3 Thanks folks!
It looks like textures outside of the camera view are discarded from memory after 60 seconds. As some of you already said, those textures do not need to be downloaded from the network again, just decoded from disk. That's still annoying. I made a couple videos for our Developers illustrating the difference between 1.22 and 1.23. just an opinion... isn't safer keep in memory all texture within "draw distance" and discard (and re-decode from disk if needed) all other?
Hoky smokes...Dan...it takes that long to decode a cached texture? I shouldn't even be able to see the delay. If there's that much work involved, maybe the decoded form should be cached.
Not that it matters much, but since I was the one to push this to Showstopper on the basis of it causing network load, and since that's not really the case, I'm dropping it back down to Critical.
Maggie's comment is pretty much what I'm wondering about now, too. Even if the algorithm changes to not flush so much from memory so quickly, something is sure taking a long time to decode stuff off disk. Maybe there's something users could be tuning differently, if we only knew what that was? The number to look at is in the texture-console: "GL Tot".
In the 1.23 viewer, you can see the number drop 60 seconds after you turned the camera. In the 1.22 viewer, textures that are behind the camera aren't removed from GL-memory. On my system, the frame-rate of 1.23 is noticeably higher than that of 1.22 in all cases. ======= Maggie, it doesn't take that long to decode a cached texture. There's a bug in the cache that makes the decoding wait for "something" on the network with the first two discard-levels, or only the first discard-level when you have the mouse over the texture. ======= Second Life 1.23.3 (121118) May 20 2009 15:45:07 (Second Life Public Nightly) You are at 251722.7, 246594.5, 406.4 in Neptune located at sim5443.agni.lindenlab.com (216.82.49.190:13001) CPU: Intel Core 2 Series Processor (2401 MHz) libcurl Version: libcurl/7.18.1 OpenSSL/0.9.8j zlib/1.2.3 A 1.23 change is coming that makes textures stay around unless they've been out of view for around 9 minutes (instead of the current 50 seconds). Viewers from 1.24 onwards have all of this code rewritten again.
Testing with Public Nightly Viewer 1.23.3 (121709), this appears to be working much better - thanks for the fix!
Not reproducing the reloading textures with with Second Life 1.23.3 (121709) May 26 2009 21:57:56 (Second Life Public Nightly)
Enviroment:
Second Life 1.23.3 (121709) May 26 2009 21:57:56 (Second Life Public Nightly) Release Notes Built with MSVC version 1400 You are at 250689.5, 240446.8, 32.6 in ParrotHead Cove located at sim4838.agni.lindenlab.com (216.82.55.234:13001) CPU: Intel Pentium 4 (Unknown model) (2800 MHz) libcurl Version: libcurl/7.18.1 OpenSSL/0.9.8j zlib/1.2.3 i have been in an area for a while with a lot of changing textuers and have my graphics set for draw distance of 256m and so far i have seen the textures and objects sticking around much better. and when i have had my cam in one place(in close on an object,playing a zyngo card) the zoom out to across the sim after having it that way for a long period of time everything very quickly reloads and is not greyed(no texture). So it seems that so far it is working again for the textures(keeps fingers crossed). Retitling. Was "Objects/textures are removed from viewer memory too aggressively". From my experience, this bug only affected textures.
Fixed in 1.23.4, released on 06/15/2009.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Critical
Textures are removed from viewer memory too aggressively
Release Notes
Built with MSVC version 1400
You are at 241067.7, 274119.6, 27.9 in Sunbeam located at sim2065.agni.lindenlab.com (216.82.16.70:13000)
Second Life Server 1.26.2.117266
Release Notes
CPU: Intel Pentium 4 (Unknown model) (2800 MHz)
Memory: 1022 MB
OS Version: Microsoft Windows XP Service Pack 3 (Build 2600)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce 6600/PCI/SSE2
OpenGL Version: 2.1.2
libcurl Version: libcurl/7.18.1 OpenSSL/0.9.8j zlib/1.2.3
J2C Decoder Version: KDU
Audio Driver Version: FMOD version 3.740000
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.23573 (Mozilla GRE version 1.8.1.21_0000000000)
Packets Lost: 45/122503 (0.0%)
The snapshot was taken after facing south for about 30 seconds the turning left to fave northeast