#SL Viewer 3.4.x Week 37

Linden Viewer updates are a bit balled up right now. This version got too many changes and fixes poked into one update. Somewhere in all those changes is a memory leak that crashes the viewer. This has caused problems. The Pathfinding Project’s formal release has been delayed, for instance, as have other viewer updates.

Third party dev’s have been splitting the various update items apart and implementing different parts of the 3.4 code in their viewers. Pathfinding Tools are mostly operational in Firestorm and their crash rate is still really low. So, the problem is not in the PF Tools. (You can now see those tools in more viewers, but not yet the official Linden viewer.)

The Lindens are trying to get a viewer version with just the PF Tools into testing with the 3.3 code. They feel that could pass testing and move to Beta and Release quickly.

The Lab is also breaking the 3.4.x updates into several packages to narrow down where the problem is. We will likely see some smaller faster updates to the viewer over the next month or so.

Andrew thinks Baker Linden’s Group Edit fixes are also caught in this problem.

Stinson Linden was trying to track down a problem not in the beta viewer but occurring in the dev viewer. A number of transition problems have popped up in the dev viewer. For me the dev viewer is just not usable when working with Pathfinding Characters. Or maybe it is just a matter of how I built my HomieBot.

64-Bit Viewer

First… not likely. There are however LAA (Large Address Aware) viewers around. Oz was asked about the possibility of getting a 64-bit Linden viewer. His response was:

We’re not doing 64 bit yet, but it’s possible that MacOS will end up pushing us to it before long (personal guess, not Linden Prediction). There are a bunch of reasons why that [64-bit] keeps getting put off, even aside from the fact that it’s not clear it would actually have much end user benefit…. it’s a huge amount of work to rebuild/upgrade the 50-odd libs we use then there’s fixing the code itself (unknown level of effort, but probably not trivial).

Then, and this may be worst of all… we’d have twice as many viewers to test and maintain – since for quite some time we’d need to continue supporting 32 bit viewers as well.

While Macs are better at supporting 64-bit apps Windows is not. Plus there is a huge base of Windows users using 32-bit. That is slowly changing, but very slowly. Plus Macs have lagged in their support for OpenGL. QuickTime has lagged in adding 64-bit support for Windows. So, the incentives and obstacles are a contradictory mess of decision points and mutually exclusive choices making it difficult to know the best course or probable outcome of any choice.


The next two or three weeks should see this hairball pass through the system. Then viewer development will jump forward. We have seen the Lab make the mistake (my word) of putting too many fixes and upgrades in a package and then getting bit trying to find a problem in a large package. This has now happened on the server and viewer sides of development in the same time frame.

It’s all a process…

3 thoughts on “#SL Viewer 3.4.x Week 37

  1. OpenGL support has very little to do with any sort of 64-bit “push” on OS X (regardless of how frustrating it is).

    The benefits for supporting 64-bit on OS X would at least be some degree of performance improvements due to OS X’s better performing ABIs for 64-bit apps. There’s also the issue of how Apple’s slowly starting to reduce support for 32-bit applications

Leave a Reply

Your email address will not be published. Required fields are marked *