We have a bit of news from the Third Party Developers Meeting from Friday, 8/29. Chakat Northspring videos the meetings. You can follow him on YouTube and catch those meetings a few hours after they happen.
Viewer news from Oz Linden is pretty thin, his word. I’ve covered most of the viewer news earlier in the week. Oz basically said at this Friday’s Third Party Developers Meeting that projects discussed at the previous meeting are still ongoing and there is no new news on them.
I think this is basically the lull in feature development and bug fixes that comes from the Lindens stopping to work on development tools and upgrade to the new compilers. It is an analogy to car manufactures that stop production of cars to retool for production of the next model year cars.
In the developers group they refer to the auto-build tools that compile the viewer. It is presently moving forward as a 32-bit and 64-bit versions. Oz says soon they will be merged into a single build process. Rather than build twice, once as 32 and once as 64, one build would produce 32 and 64 bit builds.
Currently they are having problems getting the new builder to handle Large Address versions. They are tracking down that problem and adding more license and copyright controls. Oz hopes to have things working in week 36. Once it is working then the Lab will start recompiling all their tools and libraries. That redo everything project is expected to take 2 to 4 weeks. Then SL development will return to the pattern we are more familiar with.
Don’t expect a 64-bit SL Viewer any time soon. The Lab is headed that direction. When they have an opportunity to do something that moves them closer to 64-bit they take it. But, they are not going to redo the viewer into 64-bit. There are apparently too many obstacles in the viewer. So, they are fixing them as they add enhancements that improve the user experience.
Oz is auditing the source packages the Lab uses to build Linux version viewers. Once he can be sure that he is not giving away proprietary code, he plans to make the Debian packages they use available. The Lab has updated to newer Linux compilers and tools. If things go well users can have this stuff in week 36.
At 07:00 Oz starts to talk about changing the Linux and Mac to 64-bit only compiles. If you have an interest in this listen to him explain it. There are some gotchas that prevent their going 64-only for Linux and Mac, one of which is developer time to fix the known problems.
The WebKit libraries have been cleaned up by Monty Linden. WebKit is still in use with current builds of the viewers. The WebKit libraries handle streaming media and provide the in viewer browser, which we use for things like Search and Profiles. So, viewers built using the WebKit library should handle streaming media better and generally work better. I suspect in-world TV’s and radios may work a bit better, but I am not certain about that.
The Chrome Embedded Framework (CEF) project is still going forward. I am hoping it eventually replaces WebKit. But, I get the impression from what hear there are some 64-bit issues and it is thus limited to 32-bit. That doesn’t seem to fit with what I know about CEF, which isn’t all that much.
The end result when all this is done is that streaming should work so well we can watch Netflix and Hulu in-world. Not they are problematic.
Group Chat Lag
This project was delayed due to vacations. Those are over and people are back. The group chat servers have been getting upgrades. I think hardware upgrades and operating system upgrades. The Chat experiments are waiting to be tested until the updates are vetted and pronounced good. Then the experimental code and data collection code cued to go will rollout.
There are still problems where the chat servers handling a group’s chat stall. Contact support and tell them your group messages have stopped being delivered. They have a process for restarting the problem server.
In the last two week there has been no work on specific Cocoa problems.
The Kakado software used by Linden Lab to handle the JPG2000 compression of images will be getting an update as part of the Build Tools updating.
As far as I know only the SL Viewer and Firestorm have purchased this proprietary package. The open source JPG2000 options are pretty good, but they have always had problems in my limited experience from the user side. So, I’ve always used the SL Viewer to upload textures I planned to eventually have in the Market Place or otherwise sell in SL.
You can search this blog on KDU or Kakado for articles on the problems we used to have from odd problems in image compression apparently coming from non-KDU compressed images.
I would hope the new KDU is a bit faster. The Firestorm team is making the parts of their viewer that use KDU functions multi-threaded. Multi-threading is simply about allowing the computer to do things in parallel rather one-thing-at-time. So, in a scene render, more of the computer could be used for decompressing images. The new multi-core processors like multi-threaded applications. The result would be faster scene renders.
Firestorm is already using KDU 7.4 a version or so ahead of the Lab. Cinder Roxley is working on adding KDU 7.5 to a viewer… I suppose Alchemy. But, I don’t know that Alchemy has KDU…
I gather that KDU 7.5 requires more changes to viewers than upgrading to 7.4 does. Whatever the case, viewers are getting KDU upgrades.