How to Improve Second Life Lag: Improve the Perception of Lag With a Loading Progress Bar!

So as we were talking about before the Emeraldgate imbroglio, Second Life is notorious for having excessive lag. It's a problem that'll be difficult to fix, as Philip Rosedale just acknowledged, but here's the interesting thing: Many of the most popular Internet sites also have lag. (Broadly defining "lag" as the delay between the user making a content request, and the user actually getting that content on her screen.) When you want to stream a television show online, or play a Flash game, for instance, the lag time usually lasts several seconds to several minutes. But when you sit there waiting for the latest episode of "The Daily Show" to load up, or the latest Kongregate game to play, you rarely complain, or if you do, you're much more likely to blame your broadband provider, than the site with the content you're requesting.

Why's that? Simple, really:

A progress loading bar. There's many variations, like a "Buffering" counter or a red line that slowly moves across your screen, but they all convey to the user the same basic idea: Your content is coming, but it's not optimally ready yet, so just be patient, dammit. On the Internet, the progress bar is such an ubiquitous visual cue, adding it to the Second Life experience should do quite a lot to make SL lag more bearable.

Consider the top screen capture above, of Gawk, a very cool sort of shopping-meets-Half Life 2 Second Life location, taken right after I teleported there. If you're a regular Second Life user, you know the coolness will eventually come. But if you're someone like Chris Pirillo or 99% of new users, you'll probably quit way before then.

However, consider what that very same scene would look like, with one small user interface tweak added to the top left corner:

With that one addition, the lag and the blobby gray no longer seem like permanent aspects of Second Life, but explicitly expected, acknowledged, temporary impediments. (And note that I say "Estimated progress", because I assume it'd be impossible to calculate exactly; however, you can make a best guess based on the number of avatars and prims in the sim, broadband speed, etc. etc.) On a moment-to-moment basis, a progress bar will make Second Life seem less like an undifferentiated lagfest, and more like a potentially cool graphics-heavy website that just hasn't totally finished downloading yet.

It may take months or even years to create a lag-free Second Life. But if I'm right, it would probably take a day or two of development to make it feel less laggy.

Comments

[comoro Infinity]

you have the lamest ideas Ham, you make me cry for how silly you are

[Squeebee Wakawaka]

Interesting concept, but I wonder how soon people would get annoyed by the progress bar constantly appearing every time they moved, every time another avatar moved within draw distance, every time a script changed the texture on a visible prim.

I could see this as being great for right after someone teleports, or perhaps when a threshold of downloads has been crossed (when you have flown across a sim).

I personally would also like to see the ability to "Save" a sim to disk: to permanently cache a sim that you visit regularly, exempt from your typical cache-size limits. Players like myself who typically visit one or two sims on a very regular basis could rest assured that those sims would always load quickly.

[Flashing Merlin]

Makes some sense when waiting for clothing to download, but what about the lag when you hold a cursor key and your avatar doesn't move? The progress bar wouldn't move either, for the same reason. Worse, what would the bar show when you're not holding a cursor key and your avatar won't stop moving? I find that type of movement lag to be the most annoying.

Actually the "cloud effect" does just as well at letting you know your clothing is on the way, and is a big improvement over the old days when you stood there naked waiting for your clothes to arrive.

Furthermore, the progress bar itself would use resources and contribute to the lag.

Squeebee's idea, especially a cache for objects in your home SIM, seems more useful.

[AM Radio]

A comparison to the browser is interesting. The load bar isn't enough though. Graphic designers have learned the lesson of optimized image loading for the web long ago. Code developers have long known the advantages of just in time scripting, as well as avoidance of loops, and gratuitous parsing of DOM structures.

There are many places on the grid which teach residents how to build, but rarely do any tutorials guide on best practice for logical, tiered, progressive loading at the point of need.

The entire sim model is built around an ongoing state which implies, wrongly, that everything should be running, always. Since a sim isn't going to cull or sleep unused scripts, it seems it's up to the builders and residents to understand what type of performance results from their choices. Current;y, their only real tool for vetting performance is simply logging in and hoping for the best.

More transparency into server and viewer performance, understanding of the performance information in the advanced menu, as well as education, standards, and best practice would do well to improve many sims. A high performance LSL framework SDK for builders would help provide a foundation for optimized and well thought out interaction architecture. There has been maturity in LSL script development and there are common tasks in HUDs, vehicles and weapons. Similarly there was maturity in web app development which lead to the ris eof frameworks such as YUI and jQuery which optimize and simplify cross browser performance of complex user interactions.

There may be a lack of solutions to fix performance issues, but providing a structure of standards which avoids the problem before it exists may be more logical. We're better off training everyone to be a pilot to fly a plane rather than wondering who's flying this thing after it's already in the air.

[John Lopez]

Two things related things I would like to see: First, I wouldn't mind if requesting a teleport would take a moment to pre-load the nearest object/texture data to the landing point *before* I departed my existing location.

If this was done in a way that I could "request teleport" and a progress bar appeared which allowed me to (at any time) click it to "complete teleport" (which would trigger the actual teleport sequence). Personally I would see the experience as vastly improved. It isn't like I randomly teleport around; I find a destination usually long before I need to leave for it. If I do randomly teleport I still would have the option to jump "early" and have the same experience I have today.

The second change would be to permit *much* larger caches, preferably marking "favorite places" with priority in the cache. I'm serious when I say that I wouldn't have a problem picking up a 1TB hard drive for caching if I could use it (and the SL cache algorithm could index it properly so it isn't slower than downloading). I used to own a region and I always boggled at the fact that most of the data in that region (where I stayed most of the day) had to re-download anew each day.

[Adric Antfarm]

Monty Python does silly sketches that don't do this idea justice.

It is very silly indeed.

[Trinity Dejavu]

This just wouldn't work in SL. It's silly to even suggest it.

A location in SL is determined by your draw distance, now assume you land and dont move, sure, you will download everything in range to the settings of your client.

You move. The progress bar goes back to zero.

You walk about a sim shopping, the progress bar never, ever finishes.

Turn on the stats (SHIFT+CTRL+1) and the Texture console (CTRL+SHIFT+3). Now, watch the bandidth number and the mess the texture console makes of your screen as you walk about a mall. Pretend this is a progress bar.

Turn the above off and be glad you don't have some blinking flashing bar on your screen all the damn time.

[Adeon Writer]

Both Mozilla Firefox and Internet Explorer have a green bar at the bottom of a page while it is loading that gives you a rough estimate of when everything will generally be done.

Something similar for SL would absolutely work provided it was discrete, even if it's not accurate.

[nyoko salome]

hmmm, mmmmebbe!! but i would posit that the 'wait' with webpage content is assuaged instead by the ability to instantly access another website, via another window tab - you can be in two places (or more) at once on the web. you cannot do same in sl - 'oh, this place is loading slowly; well i'll just tp off to the next place i want to explore and then come back when this place is loaded', does not translate to sl. (unless one multi-logs, but lol considering the subject is lag, that kinda defeats the purpose.)

[nyoko salome]

(p.s. however some kind of rough indicator like that, sure might help let newbs adapt... but only if it has the option to close/disable it for the oldbies too, lol cuz we'd be likely to get majorly annoyed with it.)

[Hitomi Tiponi]

I can only see this working when initially teleporting to a location - then it could show up just when a number of new textures needed loading. In a way there already is a loading indicator for textures (though not something that tells you how much is yet to come) - the texture console - when the texture loading activity suddenly drops off you know you are fully loaded.

[Arcadia Codesmith]

If you could force a pre-cache of an entire sim, it might be worthwhile. Gamers are accustomed to loading screens when transitioning between zones, and that's the appropriate place for a loading bar (not to mention some custom artwork and text to introduce the sim, if desired).

Combine that with mesh-based builds that are (presumably) more efficient to download and store on the user's hard drive, and you've got the makings of a much smoother user experience. You still need to load textures for other players, but even that would go faster if the 'static' environment was already loaded.

[Fogwoman Gray]

For those who wish to download sims to their hard drives for precaching, I would direct them to Blue Mars *grin*

[Ann Otoole InSL]

code it up and submit it to snowstorm Hamlet. That's how viewer dev works now.

[Lili]

We had a really nice little indicator that Linden Lab took out of the viewer long ago, but some of the TPV's put back in, the little green and red bars in the top right corner. I've become so accustomed to watching my bandwidth, that I installed apps to monitor speed in macs menu bar and windows task bar (menu meters for mac, rxtx for windows). If I go someplace and nothing is loading, with nothing downloading I know there is a problem. If I'm downloading a lot though, I'm happy to wait a little before getting frustrated.

So I think your idea is a good one Hamlet. Actually, I would like to have the option seeing a status bar at the bottom of the viewer, flashing through all the stuff I'm loading. It would really help to see the things that are holding you up, like that one texture or animation you always have problems with.

[Little Lost Linden]

I think this idea is a little bit like pouring perfume on a pig.

But that's ok.

Brother, life's a bitch…and she's back in heat!

[L. Knoller]

times 14.2.84 miniplenty malquoted chocolate rectify

times 3.12.83 reporting bb dayorder doubleplusungood refs unpersons rewrite fullwise upsub antefiling

NWN 9.9.10 Minitrue reporting doubleplusgood blackwhite refs "prog load bar" replaces fullwise "lag bars" ungood

memory hole:
1.18.5(3) "Search box added to upper-right corner of window; replaces old meters"
http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Release/1.18

memory hole:
1.19.1 Edit > Preferences > General > Show Search panel in overlay bar.
http://www.youtube.com/watch?v=WDpbFuL9H1I

memory hole:
1.23 "Show Search panel in overlay bar option has been moved to Advanced > UI as a menu item."
https://jira.secondlife.com/browse/VWR-16088

bellyfeel doubleplusgood !!

[Graham Mills]

HiPiHi displays a progress bar when rezzing. I found it an annoying distraction.

[Domchi Underwood]

This feature existed in SL viewer once, much nicer than Hamlet's in-your-face suggestion. Then it was removed and all we got was a lousy search box instead. After many complaints, and about 5-6 different JIRA issues, we got back bandwidth and packet loss bar meters as an option, only to have them silently removed again.

This is the JIRA issue, please vote for it:
http://jira.secondlife.com/browse/VWR-3156

[Martien Pontecorvo]

Personally, my alts and I would prefer to sit through a loading screen in which we see:

Contacting region...
Confirming region handshake...
Preloading local region objects...
Preloading local textures...
Arriving...

All the while being able to continue group chats and the like.

I have no idea how such a thing would work, but being able to immediately see what's about you while distant objects load later makes sense to me.

As for a meter, I think I'd prefer a nice analog dial for some reason. It's just as informative but less intrusive.

[zuli]

I doubt that this would work on SL. It is some nice idea but need further modify. It is because the design of SL is dynamic in nature. And their data not only restrict to avatar's current sim, but all four other connected sims (constable (1) changing with your moving which include new content, (2) adjust your graphic drawing distance, (3) another player's activities). Another new avatar coming in or create/rezz a new object is a change or increase the content. The progress bar will be possible 99% time cannot complete. User just have the signal of the content downloading is forever.

[Eggy Lippmann]

You could probably improve lag in SL with a quick fix that adjusts texture resolution based on object size. People use giant textures on tiny boxes for no reason.

The problem with SL loading times is that users are free to create whatever they want even without having any knowledge of how to properly optimize a 3D scene. You just can't possibly use 200 megs of textures and expect it to work properly :P

I've said this many years ago, when the prim limit first came up, that it was stupid, you should enforce a per-parcel texture limit, or even a scene complexity limit based on the actual polygons and megs it will take up.

[Sepp Schimmer]

The idea is as interesting as it is simple. And I think there are lots of other small things that can be implemented rather easily to reduce the experienced lag.

Finding a way to avoid showing objects until their textures are fully loaded could be one such simple improvement. I believe it would vastly decrease the feeling of lag. Showing gray surfaces and huge sculptie balls not yet in their correct shape only increase the feeling of lag without adding anything to the experience. Better priority of what objects and textures are downloaded first would also reduce the experienced load time.

Other client issues add a sense of lag where there in fact really is none. If some of those could be fixed, user experience would improve radically. One such issue is how sculptie objects aren't really drawn properly until you get close enough. Its not lag, but it looks like lag.

Philip, identify the small issues that give the most bang for the bucks when it comes to reducing the feel of lag, and do it now!

[Philip]

Lag is lag, no matter how one feels. It is not 'feel' that matters. It is speed that matters. And when there is speed, the 'feel' is not 'fool' anymore.