SLDev-Traffic 26

Open Source Portal > Communicate > SLDev > SLDev Traffic

sldev-traffic no 26

sldev discussions through September 8, 2007

Weekly Source Release Announced

This was previously mentioned in another thread, but Anthony Foster (Linden) formally announced the weekly source drop:

  We're going to start doing weekly dated snapshots of the internal
  release branch. Please be aware that this is a snapshot in time, so it
  may not build and it has not fully passed QA. As usual though, let us
  know of any issues.

Included was a link to the Source downloads page, along with md5s for the downloads.

GUI Prototyping Trick

Lawson English passes on a trick from Benjamin Linden: Pressing ctrl-t at the login screen brings up a panel defined by floater_test.xml. This is useful for rapidly prototyping new panels. Harold Brown notes that the login screen will come up much more quickly, bypassing the web load as well, by removing the URL to http://secondlife.com/app/login from panel_login.xml.

SLDev Subject Tags

There's been extensive discussion about how to better structure the mailing list in order to bring in more Linden participants, and how - or even whether - to encourage discussion without pushing some kinds of discussions off the list. The solution is going to be subject line tags, allowing SLDev subscribers to filter or highlight types of messages with mail program filters. A discussion of what tags would help move this forward occurred at MISC-642, along with a note from Rob Linden, indicating what types of discussions and inquiries are still more relevant to targeted mailing lists, such as licensing and legal questions. The discussion continued during SLDev office hours, ultimately culminating in this list. Please look at these keywords and use them in new posts.

Keeping Names Straight

Many list members frequently post with real life and Second Life names interchangeably mixed. Rob Linden posts SLDev Resident Names to help remember which poster is which.

LinKDU out of Sync

The llkdu library provided with the 1.18.3 release candidate is out of date, and causes crashes when uploading textures. These have been fixed and will soon arrive with the next release candidate drop.

"Redmapping," or Silent Disconnects

Nicholaz Beresford wants to add detection of disconnects and produce an explicit dialog when this happens. He asked whether anyone knew of a good way to detect disconnection. John Hurliman suggests looking for where the StartPingCheck and CompletePingCheck packets are handled. Callum Lerwick indicates that the client produces constant "Tried to send packet on non-existent circuit" messages at the point of disconnect, and that this may provide insight as well.

Questions About Refactoring the Viewer

Dale Glass expressed a bit of frustration. In his projects, he often needs functionality that should be generic, but which is tightly coupled with the systems using that functionality. He wondered at the best way to handle these cases:

  For instance, I've got several projects in development:
  
  Event list: shows particle and sound sources, who owns them, etc.
  
  Chat log patch: Shows who is speaking, owner for objects who speak.
  
  These are already bumping into some troubles. For example both need to
  send the RequestObjectPropertiesFamily message to the grid.
  Additionally, the selection manager does that as well.
  
  Now, what do do about it?
  
  1. As suggested by somebody else, trick the selection manager into
  requesting the data on the interesting object. I REALLY dislike this
  approach as it involves subverting something entirely unrelated for my
  purposes. Potential bizarre bugs due to putting the selection manager
  into an unexpected state.
  
  2. Just copy/paste the message sending code everywhere it's needed. This
  approach seems to be used to some degree in the viewer, for example
  ChatFromViewer is used by both LLChatBar and LLViewerCircuit::sendReply.
  This seems to be the easiest option to take so far, but it's
  undesirable. There's code duplication (probably harmless though, as it's
  my understanding that message format isn't going to change), and
  opportunities for efficiency can be lost.  If there are 3 places that
  want something, and that something can be cached, it's inefficient to
  have them unaware of each other.
  
  It creates development problems too, as having multiple feature branches
  doing that means having to deal with conflicts in the common areas they
  touch.
  
  3. Refactor the source in such a way that there's some object that takes
  care of it, and is used by the rest. This is easier said than done
  though, because this route seems to lead to rewriting the viewer in such
  a way that it's built on top something similar to libsecondlife. This
  would be a very nice thing, but it's a big project and not exactly the
  thing I have in mind when I decide to do some work on something that
  should be a small patch.
  
  I suppose a way of doing this would be to make a C++ libsecondlife-like
  library and making the viewer work on top of that. IMO this would make
  plugins much easier too.
  
  So, anybody thinks we should go with option 3 and move things around a
  bit? Anybody interested in working or already working on it?

Michael Miller makes additional relevant observations: The viewer uses a lot of globals, reimplements functionality already available from STL, Boost, etc... it lacks documentation, libraries are built externally rather than as part of the main project, and the continued dependency on VS2003 for the official Linden build.

Callum Lerwick suggests refactoring what you need, when you need it, and only what you need, and that good design will fall out of this naturally. Coco Linden changed the suggestion a bit, with explanation:

  "Refactor what you need, when you need it and only that much more
  that will allow a better design to fall out naturally. "
  
  This is because if we refactor only what we need, we can end up with
  combinations of old and new patterns which can be more confusing that
  before. I prefer to take the opportunity to leave a general area cleaner
  than I found it, and not just my own little corner. I don't try to make
  over the world, but just a little bit more. Sort of like the signs in
  the airplane restrooms that say "Please wipe the sink counter when
  you're finished." When enough people do just a little bit more than the
  minimum, things tend to slowly improve.

Zero Linden suggests that refactoring is a good idea when unit tests exist, as "having confidence that a change didn't alter the functionality of our system is low, we have a strong bias not to refactor code. Instead we code defensively, copying code, adding new methods that are variants, leaving in code we aren't sure is used, etc..." He continues:

  I would encourage us to push the balance more toward refactoring than we have.
  If you can add unit tests, do -- it is almost always worth the extra time.
  
  If nothing else, I'd recommend the following two metrics for when to refactor locally:
  
  1) Never cut-and-paste more than three lines of code.  If you need the same computation, make a function out of it.
  
  2) If a function is longer than one screenful ( ~50 lines for most of us), it is too long.  Break it up.

LLMotion Mess

Nicholaz Beresford has been investigating additional animation memory bloat introduced around 1.18.1. Nicholaz had noted bloat prior to this, which was fixed by a patch he submitted against VWR-1769, but which had to be backed out as a new 1.18.1 change that introduced additional leaks apparently interfered with the patch. Soft Linden provided a patch that refcounts LLMotion as a test, and Nicholaz verified that it reduced the major bloat but couldn't say whether it was a complete solution as his animation tests are very nondeterministic -- they depend on what other avatars are doing at the time.

Nicholaz posts a new patch to the mailing list, asking for comment:

  Well, long story short: The llkeyframemotion cache needs some attention
  as it eats a lot of memory in busy sims.  30 minutes at Bad Girls or a
  similar sim can cost up to 50MB-100MB which never get freed until you
  log off with (literally) a million of small heap blocks.
  
  If you have your own builds you may be interested in this:
  
  Builds based on 1.16.0.8 can apply the 1769 from the JIRA (it's tried
  and trusted, runs on my viewer build for a long time now) to get the
  cache flushed on teleports.
  
  If you have a build based on voice (1.18.1 or later) you need to apply
  (reverse) the attached llmotion patch if you want to run with VWR-1769.
  
  And I'm attaching a newer version of VWR-1769 which expires entries from
  the cache while staying on a sim.  That one is pretty new and more
  beta'ish, so it could use some eyeballs or comments.  On the other hand,
  one of my users who is a manager at Bad Girls and stays there for
  hours, was running it with my voice viewer and very good results yesterday.

https://lists.secondlife.com/pipermail/sldev/2007-September/004392.html

To date, there hasn't been any feedback.

Back End Features, Region Web API

A frequent question on SLDev is how one can go about implementing new features that require simulator functionality, and the answer has been that a JIRA should be created describing the needed features. To date, if any of these requests have been filed, they haven't received enough votes to be imported.

The topic came up again on the list, with Dale Glass asking about how to fetch a region's name based on the region handle. Ryan Williams (Linden) suggested that it would be helpful to compile a list of what information is publicly available about regions irrespective of access level, with an eye on offering a web service that can provide this information. There's room for someone to compile such a list and create the JIRA; this may be a good candidate to set precedent on new simulator features for open source developers.

Alternate Viewers

Nicholaz Beresford has created a listing of some of the alternate Second Life viewer applications. As usual, there's the disclaimer that Linden Lab can't vouch for the security of these builds, but all have source available if you want to diff against the reference version and analyze the changes before making your own build.

1.18.1.2 and Upward Devouring RAM on 64 Bit Build

Callum Lerwick notes that 1.18.1.2 and 1.18.3.2 are rapidly eating all available memory on a 64 bit x86 build. Nicholaz Beresford noted that he believes he has a 64 bit Vista user who experiences similar symptoms.

Consolidating Streaming Video

Ernie Kabowski inquired about whether there was interest in patches he was developing to incorporate Nullsoft Streaming Video support. Callum Lerwick and Harold Brown note that the Linux viewer already supports gstreamer, and that pushing gstreamer adoption on the other platforms might be the better route. If gstreamer can wrap Quicktime and DirectShow as appropriate on OS X and Windows, the viewer can avoid the audiovideo CODEC "patent minefield," and provide a logical place to hang new streaming formats.

Fur Shaders

This was an interesting discussion, though it doesn't look like any plans came out of it: Argent Stonecutter linked to a page about fur shaders, using many render passes of the same texture in a shell about an object with an decreasing alpha cutoff limit. The effects are pretty, and for hair effects, as a shader effect this could conceivably be cheaper than the twisted torus and flexible prim shapes making up a lot of complex hair.

Thanks for readin'!