|
History
| Log In
|
|
|
|
|
|
[
Permlink
| « Hide
]
Henri Beauchamp - 14/Nov/07 08:11 AM
I just tested it with the official release candidate (previous test was made with a self-compiled viewer): the slow down is even worst. In my skybox, the frame rate goes from 45fps before the search, to 10fps after the search... A 4.5 factor !
Oddly enough, when I did this, my framerate increased.
Second Life 1.18.5 (0) Nov 13 2007 10:25:05 (Second Life Release Candidate) You are at 245961.3, 254553.2, 401.1 in Suffugium located at sim4895.agni.lindenlab.com (64.129.47.149:13006) Second Life Server 1.18.5.73200 CPU: AMD Athlon 3700+ Memory: 1024 MB OS Version: Microsoft Windows XP Service Pack 2 (Build 2600) Graphics Card Vendor: NVIDIA Corporation Graphics Card: GeForce 6800 GS/PCI/SSE2/3DNOW! OpenGL Version: 2.1.1 LLMozLib Version: 1.1.0 (Mozilla GRE:1.8.0.12_0000000000) Packets Lost: 94/7729 (1.2%) Viewer Digest: 3fb7fa44-f6ab-e2be-f03d-dcdc760d431a This seems to be what I am experiencing too. I already commented on it on the SL forum. This is what i wrote:
Like with the REV130 SVN version, i get a horrible fluttering stutter of FPS after i opened the new search tab and closed it again with the official 1.18.5.0 RC. This goes away after a while when I keep the new search window open for about 5 minutes or so, but comes back when i close it. The only way to have no fluttering FPS is to open the new search window, wait until it calmed down, switch to another search tab and then close the window. Could this have to do with the google-perftools (namely libstacktrace and libtcmalloc)? -Asriazh P.S.: Some informations about my PC CPU: AMD Athlon(tm) 64 Processor 4000+ Memory: 2027 MB OS Version: Linux 2.6.24-rc2-git2 #1 SMP Sun Nov 11 16:32:19 CET 2007 i686 Graphics Card Vendor: NVIDIA Corporation Graphics Card: GeForce 7600 GT/PCI/SSE2/3DNOW! OpenGL Version: 2.1.1 NVIDIA 100.14.23 LLMozLib Version: 1.1.0 (Mozilla GRE:1.8.0.12_0000000000) I was just messing around with the 1.18.5.0 RC viewer a bit more and found out the framerate flutter and drop disappears as soon as you switch off "dynamic textures" (ctrl+alt+f4).
-Asriazh Can anyone on Mac comment on this? I do not see this on my Windows Core 2 Duo, Radeon X1300.
I wonder if this is our Linux Mozilla implementation doing something dumb, like constantly polling the page. All three Mozilla back-ends constantly poll the page (15Hz!), but this is probably rather more expensive to do on Linux due to the architecture (and hackery of llmozlib). The real bug would be that polling doesn't get suspended while the widget is hidden. I'll verify that this is happening.
I've attached a screen shot of the frame console after having opened and then closed the New Search feature.
As you can see, there is an immense amount of time being spent on UpdateTexStats. I'm seeing this on Windows. In general the frame rate degrades to slide show after about 5-10 minutes regardless what I do, but opening the new search causes the degradation to happen far quicker.
@Matthew
I think the problem you are encountering is a different issue (memory leaks leading to a full memory and the start of swapping, most probably). The issue we are speaking about is an -immediate- slow down after the search tab had been used. It seems to affect only the Linux version of the viewer. I've confirmed that (in this case) we keep asking Mozilla to give us updates even when this cannot be useful, which seems to be the underlying problem. Will look into a fix soon and post a patch here.
It's very likely that this does indeed affect all platforms, but is particularly noticable on Linux where the operation is a lot more expensive. Attaching patch.
The LLPanelDirBrowser widget was observing visibility changes but then forgetting to propagate that information to its children as LLView subclasses are expected to - thus the LLWebBrowserCtrl never learned that it was invisible so never stopped expensively polling for updates. LLFloaterChat, LLMenuItemBranchGL and LLWebBrowserCtrl itself commit the same sin which the patch also corrects, though the typical children (where applicable) of these widgets don't actually care right now. Thanks for the bug report!
The fix is expected to be in the next 1.18.5 Release Candidate. Thanks for the patch, Tofu. I can now use (and test) the release candidate. :-)
I applied the patch to the 1.18.5.1 source and can confirm this. Framerates now go back to normal as soon as you use a different tab than the new search or close the search window alltogether. Can we have the windlight source to play with now please? ^_^;
-Asriazh Isn't that "fixed" with the 1.18.5.3 public? I've changed all fixed internally issues to Resolved: Fix pending.
This issue was fixed in v1.18.5.1RC and never crept back up since.
Closing as Fixed. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Critical
Dramatic drop in frame rate after the first use of the new search engine.
