Baloo Uriza

I could be wrong, but isn't Windows a notable exception?

Just turn on busy mode when you need to not be interrupted.

Multithreading on Windows is generally bad at best. Par for the course on that platform, consider using an OS of a modern design.

I see the situation as a bit more of a PR move for the forum crowd. Let's face it, most of the folks on the forums don't know jack squat about the technical details, and are afraid to admit it. SL's just short-circuiting the explaination by drawing 'em a picture. Can't blame 'em, really.

I think you're wrongfully attributing the situation here. Microsoft cripples OpenGL support on Windows specifically to discourage developers from going multiplatform (since DirectX would be just one fewer level of abstraction on that platform). The GPU's themselves speak OpenGL. Windows translates OpenGL from programs to DirectX, which then has to translate back to OpenGL to get to the hardware. Even professional grade GPUs suffer performance loss on Windows compared to other major platforms, all other factors being equal. Windows is just defective by design on this.

Hiro Fluffy wrote: Firestorm has been doing this for years. I don't understand why this wasn't a "day one" feature. Not many people who have actually been paying attention trust the Emerald/Phoenix/Firestorm/Whatever-they-call-themselves-to-ditch-their-bad-reputation-this-week developers, and haven't for years. That said, good to see there's finally an implementation from a trustworthy codebase.

Perrie Juran wrote: Is there really anything that LL has done recently that has resulted in faster frame rates? Anything that really helped Client side in optimizing rendering, that has helped us get better performance Client side? The only thing that can optimize rendering, and this is true in any 3D experience, is for content creators to use the smallest practical textures and the fewest verticies/polygons possible to get the job done. Framerate is 100% on us, the residents, to be kind to each other.

No. The system doesn't even generate an event for a declined request.

Wishful thinking. Even by the most conservative estimates, Linux has 12 times the market share of Windows Phone.

There's FRAPS alternatives for Linux out there...I'm not much of a machinima nut but I do know people have done machinimas on Linux. Also, RAMdisk is implied on Linux, dynamically. Any unused RAM is used as a filesystem cache, your most recently used accessed and written to files are cached in RAM until the file's closed AND it hasn't been accessed in long enough for you to run out of space in the cache. So, creating a RAM disk for the purpose would actually hurt performance: Let the filesystem handler do it's job! If you throw excessive hardware out of the problem, you can get comparable performance out of Windows, but it is a tradeoff: You do need more resources and a LOT more user intervention to get Windows to do the same task as effectively as Linux.

I think my first boss said it best, "If you have to ask, the answer is no."

No, Windows legitimately is crippled for OpenGL applications. It's done to force DirectX on developers in an effort to make it hard to do exactly what the Lindens are doing (multiplatform support). So you can either have a single codebase that compiles on all platforms and runs crippled on Windows, or you can have something that is optimized for Windows and runs literally nowhere else (since DX is MS-proprietary). Or you can just flush all your cash down the toilet and maintain two vastly different codebases and trying to keep them in synch. I wouldn't say 3 times faster, but I would say pretty reliably you do get about 20-30% faster in terms of framerate, all other options equal.

You don't need to be watching informative murder porn. Your kids locked you out of the cable box for a reason.

Easiest way is to sidestep. Linux is good.

Voron Blackheart wrote: Question is closed. Thank you. No! Bad! Don't delete the question after the fact just because it was answered, give kudos and leave the original text. People can't search for something that's already been answered when you dick people out of the opportunity.

No, that wasn't quoted for truth. You changed the meaning substantially to the point where it's almost, but not completely, different from what the original author wrote, when that original author actually nailed it dead on the head with the word you conveinently dropped.

The biggest bottleneck for folks living in big cities with modern broadband infrastructure (ie, fiber) isn't the streaming of objects, it's rendering the scene. Preboxed games, even open source games, have standards for maximum polycounts, verticies, and texture sizes that are far and away more conservative than Second Life's, keeping performance in mind. The more verticies, the more polys, the more and larger textures, mean more lag, whether or not you have the ability to prerender it before it goes into the box and gets shipped out static. SL's environment is largely designed by amateurs, who largely don't give a **bleep** about how hard it is to render something (hair and fashion "designers" are, far and away, the worst offenders on this). SL also changes potentially in real time, so it's not like things can be prerendered cheaply; everything's rendered realtime more or less from square one every frame. You have two options: Convince your fellow residents to start playing polygon and texture golf for the lowest score, or throw hardware at the problem. Good luck with the former.

No, it's pretty true to life. Compare against prims of the appropriate proportion and keep in mind that SL is 1:1 scale.

The 0-100 values correspond to the human range of size in reality by percentile. So all 50 would be a statistically average human, and all 100 would be the largest ever in every proportion.

Learn to live without it. It's not a service of Second Life, but rather Vivox, and it breaks frequently. Shut the caps lock off and remember those typing lessons from school.

Dresden Ceriano wrote: The fact that Mick necroposted is just that... a fact. A fact which I mentioned, but never said one critical thing about. The term "necropost" is highly critical.

Yeah, I'd report the automated cars abusive. Whoever is doing them doesn't seem to have any thought or concern for other road users at all, and they're crippling the highway system with thier selfishness. If they want to run automated trams, fine, do it on their own land where it's solely their problem.

Did you check the timestamps? I'm guessing you may have reset your preferences around that time.

It is, but not for the reason you think. No rendering was previously done server side. Now, avatars are done server side, after attempts to educate wardrobe designers on how to not be a GPU-killing clock cycle whore largely failed. So it's a band-aid fix on a problem with designers not really caring about efficiency or even trying to get bang for the buck, much less best bang, which is largely a SL-specific problem. The folks building stuff on OSGrid seem to understand how to build good looking stuff efficiently, but that just goes with the territory of being a more technically minded group overall.

Go check out the wiki article on lag. I'm guessing you're complaining about client-side lag, not server side. The wiki article will tell you how to tell the difference. If it is server side, the biggest culprits tend to be poorly coded scripts, or excessively scripting around something that's readily possible without a script. In a few rare cases, physics comes into play, mostly because the Lindens are trying to shoehorn Havok into a job that would be better served much more inexpensively, realistically and reliably by Open Dynamics, as demonstrated by OpenSimulator in load tests and open to the public on osGrid.