You might take a look at this: http://sliki.info/wiki/Optimizing_the_Performance_of_Second_Life

Running the viewer in Windows on the same machine via Boot Camp results in a perfectly smooth experience.

From what I have heard, the NVIDIA openGL drivers for the Mac's are not nearly near those from ATI yet.

Another thing you can try in regard to memory (this may save up to 180MB memory) is to reduce the setting for preferences, adv.graphics to 128MB.

It does "feel" like a NVIDIA driver issue - on occasion I'll see texture corruption, particularly on un-rezzed or partially rezzed textures. It's a little curious that other OpenGL applications seem okay, though.

When I boot into Vista using Bootcamp, then Second Life runs extremely fast and I usually get 40 FPS or better, even with settings at 128m Draw distance, maxed out detail settings, all graphics features turned on. I always get about twice the FPS in Vista that I ever get while using SL in OS X (even with minimal settings). So something is definitely wrong!

Also in Vista, there is NVIDIA Control Panel where I can force Anti-Aliasing to be used for Second Life, and it works great and is utterly gorgeous! There is NO NVIDIA Control Panel on the OS X side, which must be some kind of vast oversight on the part of Apple and/or NVIDIA??

Also, Avatar Vertex Program remains grayed out on the Mac side no matter what. It will not turn on. I'm not sure what it does, since my avatar looks the same with or without it, but it did not used to be grayed out on my PowerBook G4. Maybe this is related?

» https://jira.secondlife.com/browse/VWR-1749#action_21942

I'll also ask Poppy if there's any new info which should be here. We'll keep you posted.

I have been trying different things in order to try to keep the viewer running as long as possible without having to relog and I think I found one way to extend the usability period until you have to logout or crash. Basically, when I see the VM approaching the 2GB mark (I have 3GB RAM), I switch to full screen using Option-Enter, then back to window mode. I've seen the viewer going from over 2GB of VM down to 1.5GB just by the switch. However, that trick seems to work once or twice if you're lucky. At some point, the laptop freezes. In any case, the driver seems to be the problem based on previous useful analysis but it seems that the viewer is somewhat related too. Or else, how explaining that around 500MB of VM are released just by switching resolution?

I see the same results with SL that have been reported here - system resources start getting consumed and held and then crash. Nothing seems to stop it. I also see the weird texture corruption as well. I have the issue with the pre-voice and post-voice clients.

I've since loaded Windows vista w/ Bootcamp - not one issue - no crashes - and I get much better performance. Only Catch-22 is that the drivers with Bootcamp for Vista won't let me set my external display at anything greater than 1024 X 768 - so I have to use my laptop screen with SL to get a decent resolution.

Anyone that can solve this will be my hero. At this point I'm so close to returning the MBP and getting something else. It just doesn't make any sence to spend so much on a top of the line system that crashes all the time.

This is getting really old. Please let us know if the new 10.4.11 seeds improve things? Sorry for cross-posting this to the other thread but I want to know (a) if crashes gets fixed and (b) if performance gets fixed.

-Gistya

Hi everyone,

I have been in contact with Apple regarding this issue. This is what we know:

• There are driver issues specific to the nVidia 8600M GT on MacBook Pros.
• Apple knows about this.
• nVidia knows about this.
• Other graphics-intensive apps are seeing similar issues.
• There is no date for a fix right now.
• I am having regular follow up calls with our Apple Partnership Manager.
• This is high priority for Second Life, but there is not much we can do at Linden Lab.

I am sorry for the lack of updates. I'm not convinced this is anything more than a summary of what we knew before, but I'm hearing that's better than silence.

Another workaround (aside from relogging) is to toggle fullscreen modes. This deletes and re-creates your GL context. Thanks to Runitai Linden for that insight, and other debugging help.

Second, one can reliably, always, crash SL on my MB Pro NV 8600M GT, by setting Client:Debug Settings:RenderGlow --> TRUE
it is an instant crash.

Hope this helps.

To add something, today I upgraded from 2GB to 4GB memory (YES!) I monitored the memory leak whilst subjectively judging the performance. I found the following:

Actions: walking around, turning, heavy camera movings with disabled camera constraints. Most perfromance slow downs recognized when passing moving lights, like in dance clubs.

1. Windows XP/Bootcamp: flawless perfomance as expected
2. OSX (most recent updates installed)

• Performance estimated 60% compared to XP
• memory usage increases constantly. VM increases even more rapidly, but still no swapping. Within about 5 minutes the prefromance goes down dramatically, however still is kind of playable. Feels similar to running SL on my MacMini, however, still further degrades slowly.
• When VM exceeds 2.xGB swapping comes up and the machine almost freezes. Almost means, still usable with veeery poor performance. After another 10 Minutes. Almost stopping completely.

• Upgrade 2GB -> 4GB:

• same as above, execpt:
• VM size increase seems to stop at about 2.5GB
• Performance keeps being very poor, but no hang up or freeze encountered. (needs to be confirmed by playing longer time, however playing is anything, but fun, so I did not use SL longer under OSX)

Conclusion: even 4GB do not solve the problems at all. I also used to play SL on a 2.17GHz machine aith AI graphics and have been so impressed. My new machine is also brilliant - but I can play SL only under Windows, which I don´t want to do at all.

Please, please solve these issues! It is a shame for both parties, Apple and Linden, that still no progress can be reporteted.

Sorry, but this is my honest opinion.

From my perspective it is a must to rate the MBP with 8600M GT graphics as not compatible!

Hi everyone,

There is a new workaround for this issue. Scot Linden discovered that you can use a different driver for this video card and the computer should not crash. He wrote up instructions on the Second Life wiki. Apple has not committed to a date for a fix, but this workaround should help. Hope it works as well for you as it does for me!

https://wiki.secondlife.com/wiki/MacBook_Pro_2007_Graphics_Freeze_Workaround

+ poppy

Thanks Again,
Colin

But I am not forced to boot XP any more in ANY case related to SL - that´s a great improvement!

Thanks a lot again.

Total number in stack (recursive counted multiple, when >=5):
21 _pthread_start
21 thread_start
8 _pthread_cond_wait
7 PrivateMPEntryPoint
5 pthread_cond_wait
5 semaphore_wait_signal_trap

Sort by top of stack, same collapsed (when >= 5):
semaphore_wait_signal_trap 1655
mach_msg_trap 1323
__semwait_signal 993
semaphore_timedwait_signal_trap 971
mach_wait_until 620
select$DARWIN_EXTSN 331
select$DARWIN_EXTSN$NOCANCEL 331
syscall 331
kevent 315
FSOUND_Sockbuf_UpdateThread 171
FSOUND_Stream_UpdateThread 129
FSOUND_AsyncThreadCallback 73
_pthread_cond_wait 22
_monitor_file_descriptor_ 16
Sample analysis of process 352 written to file /dev/stdout

I know it's hard to tell without actually knowing everything that has been going on internally, but this has been a very difficult issue to find the exact cause of and likewise to fix once we knew the cause. Apple deserves a LOT of credit for how extremely, extremely helpful they've been to us in tracking this issue down and helping us solve it and I personally can't thank their devs enough.

In the meantime has anyone got any resources showing the performance or screenshots using the workaround? If it's usable, and the fix is hopefully finally around the corner, it might be worth going ahead. Maybe someone could attach some snapshots of the workaround here, or (better) on the wiki? I'd love some insight on how effective it is and if its' worth a compromise for now....

Keep in mind that this still leaves the freeze and memory leak issues unsolved, as they are Apple driver issues and cannot be solved from our end. However, they know the root cause of the issues and have made great progress on them (I'm not allowed to talk about details due to NDAs).

One part of your comment makes me concerned and I like to understand things clearly. Is following table correct? Edit: it seems that space characters are eliminated when submitting a comment, so my table lost the layout and I had to change it, sorry:

Issue / Root cause known / Responsible / Fix pending / Release
1) Shaders fall back to SW (low FPS) / Yes / Linden Labs / Yes / next Windlight Viewer
2) Memory leak / Yes / Apple / Yes / TBD
3) Viewer Freeze / Yes / Apple / Yes / TBD

If this is correct it seems to be important to continue applying public pressure on Apple. It also proves, that the "we blame each other" between Linden and Apple has waisted months of time, which should have been spent into bug fixing work....anyway.

Concerning the NDA, which obviously does not allow you to tell anything about things happening at Apple. Last time we read such comment from Poppy just before the release of Leopard 10.5.0, which gave us some hope to have the bugs fixed after. However, the opposite came true. Systems running SL on 10.4.10 smooth before (iMac 20" with ATI 1600) can not run SL on Leopard up to now, as it is painfully slow and stuttering. Hopefully pointing to the NDA this time does not mean same negative outlook again....?!

However, I need to clear up some things regarding your blame comment and wasting of time. We've never actually blamed each other. We've been working together for months to both isolate the root causes of all the issues we were seeing and actually fix them. These issues were actually very hard to actually track down as the link between the symptoms and what was actually triggering them was extremely convoluted. It took a lot of work and a lot of active collaboration with Apple to get this far.

Anyways, please be patient. There is actually light at the end of the tunnel.

thank you for your feedback. It is really good to know that things are on the way.

Again, this blame comment... It mainly seems to be a communication issue, because if you see the history in this thread and the relating ones, you will easily sense a massive frustration and also doubts about that anyone at Linden or Apple had taken serious actions for quite some months. I was among the complainers and if I have been wrong, I apologize.

In fact, only since you took responsibility we immediately could see progress, which is a great thing! Thanks so much for that. On the other hand almost 8 months time certainly are enough to fix even a complex software problem. It´s just a matter of resources put into that, I am sure you will agree. This leads us back to the insufficient bug fix management at Linden I pointed to before. Am I too demanding in this regard?

There are a great many counterexamples to that, Rush. You can easily see from the comments here how confused people have been over the cause(s) and what is relevant or not to this issue. I think we should just be satisfied that people have been working on the problem and have apparently come through with a solution.

Does this NDA keep you from answering questions as simple as: "Do the latest 10.5.2 seeds or the graphics update fix the problem?"

I don't see how an NDA can possibly cover something like this, since that information in no way hurts Apple. Not to mention I see a LOT of people talking about new features and fixes in 10.5.2 on the net, so I doubt the NDA is that broad.

• Yes. NDAs by definition do not allow us to discuss anything that is confidential. At all. Not even a little... Anybody that has actually disseminated any real information regarding any theoretical future releases by Apple has broken an agreement and would probably get into a LOT of well deserved legal trouble if caught. This is how business works and is very much a good thing. Otherwise, cooperation between separate entities would be very difficult and significantly more cumbersome. For what it's worth, we're covered in a similar fashion.

1) The viewer comes with graphic settings to lowest by default. This gives FPS in the range of 25-28FPS with non-moving textures

2) Adjusting the graphic settings to "High" and viewing distance to 256 or 320, as I have it when using SL with Windows XP, reduces the frame down to 8 to 11FPS compared to 15 to 20FPS on WIndows.

3) Once moving textures must be displayed (e.g. from even distant Disco lights), the viewer stutters and the performance drops down to 3FPS. The Windows version offers 15FPS under exactly duplicated conditions.

4) The viewer crashes the entire OS after about 20 minutes of playing. This seems to be inline with your comment, that this bug has not been fixed by Apple yet.

5) The CPU load is about half compared with the earlier SL versions. This proves, that now the graphics card hardware is involved instead of pure SW rendering before.

Conclusion: a GREAT improvement of about 400% in FPS compared to before! But this is by coming from 0.7FPS to 3FPS... Anyway, obviously you found a way to get the nVidia hardware to work. But there´s a lot to do to improve the FPS, especially as the Windows and Linux versions set a high benchmark. FYI, I play WoW on the same machine on 10.5.1 with 25 to 30FPS...

I am looking forward to the next driver updates from Apple to fix the viewer crash and memory leak issue (memory leak seems not to crash my computer, possibly because I have 4GB RAM?). Please keep on going for OSX FPS - we need a bit more, if possible!

Thanks a lot for your work, BigPapi!
Knd rgds Rush

Second Life 1.18.6 (77495) Jan 22 2008 15:22:55 (Second Life WindLight)
CPU: Dual i386 (Unknown) (2400 MHz)
Memory: 4096 MB
OS Version: Darwin 9.1.0 Darwin Kernel Version 9.1.0: Wed Oct 31 17:46:22 PDT 2007; root:xnu-1228.0.2~1/RELEASE_I386 i386
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: NVIDIA GeForce 8600M GT OpenGL Engine
OpenGL Version: 2.0 NVIDIA-1.5.18
LLMozLib Version: 1.1.0 (Mozilla GRE:1.8.0.12_0000000000)
Viewer Digest: 533331b6-3eaa-6098-1e05-6afc1ff7414c

I notice that there are no screen shots of this "pinking" would it be helpful to post some up? Not too sure if this is a common issue, like the memory leak.

It's good to realise that this is problem is being dealt with. Lets all hope for a speedy conclusion.

Second Life 1.18.6 (77495) Jan 22 2008 15:22:55 (Second Life WindLight)

CPU: Dual i386 (Unknown) (2400 MHz)
Memory: 4096 MB
OS Version: Darwin 8.11.1 Darwin Kernel Version 8.11.1: Wed Oct 10 18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: NVIDIA GeForce 8600M GT OpenGL Engine
OpenGL Version: 2.0 NVIDIA-1.5.8
LLMozLib Version: 1.1.0 (Mozilla GRE:1.8.0.12_0000000000)
Viewer Digest: 533331b6-3eaa-6098-1e05-6afc1ff7414c

Despite all the good natured vitriol exchanged on this issue, may I timidly inquire if this bug also relates to mac pro (not macbook), xeon based systems too? I've looked around in jira (what does 'jira' standfor, btw? I've often wondered...), and could find no clear hit.

I'm seeing crippling performance in all recent RC and WindLight viewers despite my best tweaking efforts and think it's germane to this bug.

I'm a casual OpenGL developer (arguably) not completely inept and would welcome any insights or opinions on this.

Fairly bummed cuz I bought the pro for SL development, but so far it's been violently unusable

[nVidia GeForce 7300 GT on mac pro 2007 edition (quad core xeon) & Leopard.]

As Edwin Star almost sang
"JIRA (huh!) what does it stand for? Absolutely nothing!"
I had the same question, it looks like that it's just a brandname: http://www.atlassian.com/software/jira/

I don't know whether you are aware of the "workaround" that (presumably) most of us sufferers are using

https://wiki.secondlife.com/wiki/MacBook_Pro_2007_Graphics_Freeze_Workaround

but it might be worth a shot to give that a go on your machine, just to see if it will stabilise SL as it has done for me. It's a bit of a fiddle remembering to select the different driver each time you start up your machine and log on, but it's far better than suffering a system crash every 20 minutes or so.

Good luck mate.

Really helped a lot... SL is almost usable again.

Now I can get back to moaning about Apple's share price

Grats, eh?

As I posted before I can see some improvement, but still the fps is unaccetably low and the viewer still crashes after about 20 minutes. The latter seems to be related to unresolved issues inside the Apple graphics drivers. In my German SL forum I started an initiative to collect performance comparison data from all Mac users there. Obviously no one uses 10.5.1, as SL des not perform well under 10.5.1. All use 10.4.11 or XP. Unfortunately on the concerning MBP w/nvidia 8600 graphics neither Tiger, nor Lepard do work....

Any comments are welcome.

@BigPapi: I know well that your hands are tied by an NDA with Apple. Does this allow you to give a hint to when we can expect the driver big fixes from Apple?

There is really no point whatsoever, at all, to complaining about performance before getting the graphics patch. You've still not eliminated one of the major variables in the equation.

Thanks a lot for your hard work on this problem, BigPapi. I really hope this finally resolves this issue.

An interesting result from my investigation about SL/OSX so far is, as said, that independent from the computer type people seem to clearly prefer 10.4.11 instead of 10.5.1 for performance reasons. According to that most other applications have been speeded up on Leopard, SL not. In opposite, movements are not smooth, etc. Is there a JIRA thread about this phenomenon? I couldn´t find any.

Installing it now. We'll see what happens.

So you'll need to update to 10.5.2, then install the Leopard Graphics Update 1.0.

Just a heads up.

Performance still peaks at about 5-10 frames per second. Not acceptable, sorry. Issue not resolved. No apparent crash, though.

Edit: Still experiencing freezing.

Have you downloaded the update yet?

[UPDATE]: Nevermind. The "Software Update" found it after the 10.5.2 Update was finished...

Can you describe the freezing (full system freeze, or just second life unresponsiveness)?

Where are you seeing 5-10 fps? How many avatars are on screen? What are your graphics settings? If possible, can you give me your performance figures on the 4 tests located at "First Look Isle"? Make sure each part of the scene has finished downloading, so that your framerate corresponds to the actual renderer and not network updates.

Are you sure you installed both 10.5.2 and the graphics update?

I'll try this version on one of our 8600M MBPs, as the pre-release versions had in fact solved these issues. These issues should have been solved with 10.5.2, so I need more info to determine what is going on.

Thanks!

I have both 10.5.2 and the graphics update. It's 5-10fps in any situation, anywhere in any populated sim regardless of avatar count. Sometimes, moving the camera quickly will spike it, specifically if I put the camera over the head of my avatar. It starts out around 30 and then slowly begins to drop. 5-10 is steady regardless of surroundings, though I've noticed that being indoors (surrounded by prim structures) causes a drop. As my avatar rezzes there's a substantial drop in framerate to around 6. Freezes are full-system most of the time.

Graphics settings are on 'high'.

Test results on first look island:

Test 1: 20.8fps
Test 2: 20.1fps
Test 3: 4fps and a freeze (seems the culprit!)
Test 4: All over the place between 30 and 40fps.

All the tests performed at about a quarter speed with my avatar in view.

Most noticeable performance drop occurs when I turn my carmera in the direction of test 3 which caused every one of the symptoms that we previously experienced before the graphics update.

Hope that helps.

Once the performance dropped down to 4 fps or even below (see attached picture <WindLight 10.5.2+Graphic update 1.0 _002.jpg> showing 1.3fps on a SIM with no avatars, except me!) it sticks to that and won´t recover reasonably. Interesting: the whole machine responds very poor, as if the CPU ratio would be 100% all the way - but it isn´t. As I took the attached picture both cores showed may be 25-30%, but he machine is so slow, that it is difficult to even type a simple text, as this one.

FYI, under Windows same place, same time, same machine, same settings: 15fps, no remarkable side impact to computer performance compared to above.

Other findings:

The spinning Beach Ball still occurs each few Minutes for about 8 to 10 seonds. During that one of the cores is up to 100% and the application doesn´t respond.

Vertex Open GL Ojects must be enabled, this improves performance

Any time hardware settings are changed, the performance goes up for a limited time to fall back to low fps after seconds or minutes

In areas with a lot of textures and smoke (the typical freeware Hobo barrel) Avatar moving and camera moving does cause very inkonsistent fps rates, the picture quite often stucks, which does not happen in the Windows version that way. If the camera comes close to the smoke, fps go up, the more away, the worse the fps.
Can this relate to the issue to filter hidden textures to not display them?

EDIT: I tried finding spots showing similar fps drop effects on the First Look Island as I experience elsewhere. I could reproduce it in principle by moving my Avatar INSIDE the boxes of test 3 (147,77,22) and turned him to view the moving objects of test 2. No mouselook, just standard view. The performance dropped down from 25 fps to about 10 fps and the display became stucky. It seems to be an issue to have objects and textures around the avatar when displaying distant moving objects or particles.

Another concern is, that the textures used on the test objects are very simple (small), whilst in the SL world we find higher resolution and size textures more and more on buildings, signs, etc. Considering the temprarily positive effect of reducing the texture buffer, could this be another hint?

Unfortunately I am not expert enough to point to something more particular, but I am open to meet with somebody in world to jointly find out!

In fact you and Apple made a big, big step forward and since yesterday it is possible to play SL on the MBP with 8600 graphic card! Many many thanks for that huge achievement. This is so much appreciated.

However, there still is some work to do, that´s why I concentrate a bit on pointing to that and try to support. There are major drawbacks compared to the Windows version and still I will use the Windows version for "serious" SL play, not the OSX one. This still is too unstable and offers much less graphics fps performance, than the Windows version.

But things are on the way, this is a quite good feeling.Thanks again!

FPS seems improved but I don't know how it compares with Windows. This bears investigation.

After upgrading to 10.5.2 and installing the graphics update, Windlight performance seems much improved though I still see the beachball fairly often. I'm delighted by the improvements but we're still not out of the woods.

What diagnostic data would help you at this point? I should still be running the latest Windlight viewer, right? I have about 20 years of Unix use under my belt, so don't hesitate to throw lots of command-line stuff at me.

However, I need more info to be able to actually narrow down the cause. So I have three quick tasks for anyone seeing this issue that would help me track down the cause of this issue faster:

1. Please post a slurl here to any location than causes the slowdown issue on the WindLight client with 10.5.2 + graphics update.

2. I suspect the issue lies in video memory usage so it would also be helpful if you can press "control+shift+1" to bring up the frame stats. Click on "Simulator" so that section collapses. Now, expand "Advanced" and then expand "Texture". I'm interested in the value that appears in "Bound Mem" at the very bottom of the Texture section. Please note what this value is at for corresponding slurls (and viewing directions) that trigger this issue. Ideally, there will be a threshold in "Bound Mem" above which we can see the performance slowdown and below which we do not.

3. Does setting "Preferences -> Graphics -> Hardware Options -> Texture memory" to a value smaller than this "threshold" help things?

While frozen:
Total number in stack (recursive counted multiple, when >=5):
10 _pthread_start
10 thread_start
6 _pthread_cond_wait
5 pthread_cond_wait
5 semaphore_wait_signal_trap

Sort by top of stack, same collapsed (when >= 5):
semaphore_wait_signal_trap 1505
mach_msg_trap 601
__semwait_signal 301
select$DARWIN_EXTSN$NOCANCEL 301
semaphore_timedwait_signal_trap 269
mach_wait_until 157
FSOUND_Stream_UpdateThread 142
_pthread_cond_wait 24
iokit_user_client_trap 5
Sample analysis of process 956 written to file /dev/stdout

While not frozen:
Total number in stack (recursive counted multiple, when >=5):
62 gldGetTextureLevel
16 gldUpdateDispatch
15 mach_msg
15 mach_msg_trap
14 LLOctreeTraveler<LLDrawable>::traverse(LLTreeNode<LLDrawable> const*)
13 LLJoint::findJoint(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
10 _pthread_start
10 thread_start
8 IOConnectCallMethod
8 io_connect_method
7 LLSpatialGroup::rebound()
7 LLView::draw()
6 _pthread_cond_wait
6 glDrawRangeElements
6 gleDrawArraysOrElements_VBO_Exec
6 std::_Rb_tree<LLViewerImage*, LLViewerImage*, std::_Identity<LLViewerImage*>, std::less<LLViewerImage*>, std::allocator<LLViewerImage*> >::_M_erase(std::_Rb_tree_node<LLViewerImage*>*)
5 LLFontGL::render(LLStringBase<wchar_t> const&, int, float, float, LLColor4 const&, LLFontGL::HAlign, LLFontGL::VAlign, unsigned char, int, int, float*, int, int) const
5 LLOctreeCull::traverse(LLTreeNode<LLDrawable> const*)
5 glBegin
5 gldInitDispatch
5 io_connect_map_memory
5 malloc
5 malloc_zone_malloc
5 operator new(unsigned long)

Sort by top of stack, same collapsed (when >= 5):
semaphore_wait_signal_trap 864
semaphore_timedwait_signal_trap 423
mach_msg_trap 248
mach_wait_until 231
__semwait_signal 216
select$DARWIN_EXTSN$NOCANCEL 216
gldGetTextureLevel 21
FSOUND_Stream_UpdateThread 14
Sample analysis of process 956 written to file /dev/stdout

That's the abbreviated process samples. I'm happy to post the entire things. Hope this helps!!!

Can we triangulate on the differences between windlight and dazzle, or am I hallucinating (again)?

The beachball is back, about 20 second freezes ever 2 minutes.

SL... the only thing that can grind my quad-Xeon Mac Pro to a halt.

This is just sad.

1.20.0.84432
MBP 2.2Ghz 8600m
OSX 10.5.2 all latest firmware software installed

Re: (ahem) Beachballing

I applied Michael Schlenker's bypass (from the SLDev mailing list):

(in llviererstats.cpp around line 692)

agent["agents_in_view"] = LLVOAvatar::sNumVisibleAvatars;
agent["ping"] = gAvgSimPing;
agent["meters_traveled"] = gAgent.getDistanceTraveled();
agent["regions_visited"] = gAgent.getRegionsVisited();
// agent["mem_use"] = getCurrentRSS() / 1024.0;
agent["mem_use"] = 100.0;

... and have hardly seen a beachball yet. More testing needed though.

Ellen Demina seems seems to be zeroing in on the same bug , per yesterday's entry on this Jira: https://jira.secondlife.com/browse/VWR-1715

I installed Leopard on my 07 MBP with the infamous GeForce 8600. It was against my better judgment, because I'd heard bad things, but after seven months, I am getting desperate.

SL performed worse. No surprise. BUT THEN! About five days ago, Apple did a big update. And... no hard crashes. Not one. I'm spending a lot of time on SL5B right now, putting up a display, and its fairly laggy there. Maybe 5 hours per day with that and other work. Using the Release Candidate. No hard crashes.

A little beachballing, maybe – slowdowns, and sometimes I had to reboot, but I am getting all sorts of work accomplished.

But who knows. By posting this message, I may have jinxed the whole thing.

LL, pls put some nice real Mac Cocoa programmers on this ?

Please ?

I've got to admit it's a lot better, if nigh on disappeared now. With the arrival of 1.20 (iirc - whatever client had Spacenavigator support in it) I can use sl quite happily again with having to resort to using the gl buffer/video card "work around" - which means that I can also enjoy windlight features (reflections and glow)! Though I still get crashes*, it's no way as regular as it was and is quite usuable. I'd almost go as far to say that I'm happy.

I'm not too sure if my experience is unique - I hope other responders can offer feedback.

*doesn't everybody?