Phoenix Viewer Closeout?

Interest List

A third part of the Shining upgrade project is how Interest Lists are to be handled. An Interest List is about the viewer sending the servers a list of things it is interested in rendering. The idea is the things you are most interested in will render first. If you are acutely attentive you may have a chance of noticing that doesn’t happen now… like if you login and look at your screen…

That too will change. The Interest List process is being reworked. The server can figure out what you can see and send just those things. However, the server doesn’t know what you have in your cache. A new more efficient information exchange using HTTP  will reduce what the server has to send you. Plus it will render the things nearest you first, or at least that is the idea.

Older viewers that are not updated will not be able to take advantage of the new process. Right now, it is thought this change will not necessarily break older viewers. But, they will be slower and place more load on the servers.


The Lindens are not handing out timelines. HTTP is the foundation for many coming changes. So, it will arrive soon. Avatar Baking needs the HTTP for it to work, so it will arrive ‘pretty soon’. Interest List changes depend on HTTP and some other things and will arrive after the other two.

Translating ‘Linden Soons’ into real time, we could see likely see HTTP changes coming in 2 to 4 months. They may show up earlier in ADITI and there will be a project viewer. In this change some significant portion of the time needed will be giving Third Party Viewer Developers time to integrate the new code into their viewers. So, timing is not solely in the hands of the Lab. TPV Dev’s may have an influence on release dates, and certainly on when various UDP services are shutdown.


There will be some level of drama has some scream, whine, and cry about the changes. There will be lots of questions about will my viewer die? Which viewers will die? I think I can answer that question. I think any viewer that is not being upgraded will definitely die and probably before the end of the year.

Some viewer dev’s may choose to stop developing a viewer. Kokua is getting closer to ready, so Imprudence is likely going to end. The Firestorm Team has an excellent viewer out in Firestorm 4.1.1. They said months ago they were going to stop upgrading Phoenix. I expect that to REALLY happen this time. Of course SL Viewer 1.23.x is doomed.

Other viewers Like Cool VL, Singularity, RLV, and others that update regularly are likely to get the needed updates and continue on. Viewers based in V3 code can easily continue.

So, as drastic as some of the claims sound, there will be little impact on the field of viewers or Second Life, other than Second Life will perform better… for those on current viewers. The problems are for those that run older computers with CPU’s that lack SSE2 support. Those computers will have to upgrade or give up Second Life. That is sad, but kittens, as cute as they are, grow up and that is life.

16 thoughts on “Phoenix Viewer Closeout?

  1. We won’t be replacing all uses of UDP – there are still plenty of things for which it is and will remain the right thing. For example, position updates for things in the world make more sense to send via UDP – if one is lost, the next one corrects it anyway, so having the underlying protocol resend is a waste of time and makes successful deliveries less timely.

    But for things like transferring image files, HTTP is significantly better when used well, so we’re going to transition those uses that make sense.

  2. I kept reading “Composting Service” —– some kind of Freudian expectation slip I suspect.
    You are right about the crying and wailing, “SL has run perfectly well on this computer I bought for $400 in 2006, why have the Lindens forsaken me?” and such.

  3. A more efficient solution to using the Current Outfit folder has been proposed by Henri Beauchamp of the Cool VL Viewer :

  4. Another thing I would like to point out is that both Jessica and Tonya have never really liked updating the Phoenix Viewer and that it was carried out mostly by LordGregGreg and a few others on the Phoenix/Firestorm team. There website in fact, is still The Phoenix Viewer website, not The Firestorm Viewer website. I would wait until an official announcement is made before jumping to conclusions that The Phoenix Viewer is dead.

    • You wouldn’t jump. I probably would.

      There are hold outs that keep working with converting V1 and Snowglobe code to work with new V3 code. That may well happen with Phoenix. But, those viewers are falling behind and I think they will likely continue to fall behind. I think Henri’s Cool VL Viewer is probably a unique exception. His is V3 code based with a V1 interface. He waited for the Lab’s development direction to stabilize then made Cool VL. He seems to stay current. If one wants to stay in a V1 interface, Henri’s is a good if not the best choice, IMO.

      • As far as I understood it Henri’s viewer is Viewer 1 based but includes various elements that are Viewer 3 based – most notably the rendering stream. Of course Henri has modified much so maybe such definitions are not so useful.

        • Henri has been vocal on the point. So, unless I’m misunderstanding him, it is V3 code with a V1 interface.

          • Starting with v1.25.0.0, The Cool VL Viewer was based off Snowglobe v1.5 and some of the v2 code (alpha and tattoos, inventory links, etc) where backported to it (in fact, some code was already backported to the Cool SL Viewer v1.23 and even v1.19.2, which were based on LL’s v1.23 and v1.19.0.5 respectively).

            With v1.26.0, more and more v2 code was incorporated, replacing the corresponding Snowglobe code. This was particularly true of almost all the project libraries (all the ll* directories in the source tree that are not inside newview/ but along it), but also of many classes in newview/ (texture fetching (HTTP) and caching related, for example, but not only).

            With v1.26.1/2, things went even farther since it saw the inclusion of all the rendering code from v2.6 (with further improvements/fixes coming from v2.7, 2.8 and 3.0). More newview/ v3 code was also backported (new web search, inventory changes (HTTP fetches, marketplace support…), etc, etc…).
            The mesh versions of Phoenix are in fact based off the Cool VL Viewer v1.26.2 (at least for some of the ll* project libraries needed by the mesh code, and of course, the mesh renderer).

            With v1.26.3/4, the whole texture layers, parameters and avatars compositing/rendering code was backported from v3.2 together with more inventory code changes (which brought multi-layers clothing support) and even more code was updated/backported from v3.2/3.3.

            With v1.26.5, I’m currently backporting the v3.3 renderer…

            And the story continues and will continue as long as I am intested in SL/OpenSim…

            One thing is sure: I’ll keep the Cool VL Viewer up to date with LL’s viewer while keeping the v1 UI (unless LL comes up with another UI that can beat v1’s efficiency, but even the v3 FUI is still *very* far of that !).

            So, yes, the Cool VL Viewer is *mostly* a v3 viewer with a v1 UI, even if the UI-related code often goes deeper than just the way the UI elements are drawn on the screen (the inventory, for example, is dealt with in the v1 way, which presents quite some differences from v3), meaning there is still some non-UI-only v1 code in the Cool VL Viewer…

  5. I am very glad to hear that the lab is pushing forward with changes to the infrastructure. You can only hold on to the past for so long. Microsoft spent far to many years fighting to maintain compatibility, and it hurt them. I am happy that LL is moving forward even if it does mean that some of these older viewer will cease to function. I am very happy to hear as well that consideration is being given to each function to pick the best protocol to deliver that functionality. I am very, very excited to see what happens over the next 4 – 12 months in SL.

      • In this context, the word “exciting” scares me.

        I want the way the Viewer talks to the servers to be boring. I don’t want to be surprised. I don’t want to notice things happening, or not happening.

  6. I hear that one or two bad decisions were taken in the original use of HTTP, involving the keep_alive option, and current viewers have adapted to cope. It’s that adaption which is straining routers.

    It would be simple for Linden Labs to make sure that keep_alive was turned on for existing servers, but the Viewer adaptions could then backfire badly. A large number of HTTP Sessions would be opened to get around the lack of keep_alive, and if they requested keep_alive anyway, they would stay open.

    That’s the story I heard. It makes some sense to me.

    Fixing this mess needs good communication on the part of Linden Labs. They do seem to talk a bit more to the developers than they do to us ordinary residents, but fixing this needs the developers to produce viewers that don’t behave badly when keep_alive is active, and it needs residents to be confident they should use them, and all this lined up for when the Lindens push the big red button.

    Linden Labs do not have a good reputation for communication. And residents do cling to the old, the familiar, and the predictable. (I didn’t switch from Phoenix to Firestorm at the first opportunity). There might be horribly complicated ways of making the Viewer switch automatically when it notices keep_alive is working. Even if that is simple, it will need testing.

    This isn’t going to be fun.

    • Well… the Lindens in general exhibit better communications skills than the community of users does.

      As the Lab moves their product to use more multi-threaded processes the HTTP communications will have become fastidious about closing connections.

  7. I mean… why all this time wasting? The V3 interface is amazing. Minimalistic, professional looking (The gray tone matches the most advanced UIs like by Adobe, and nowadays many others are starting to adopt this kind UI. No confusion, no fancy elements. A contestual menu is faster than a pie menu.

    It’s not my opinion – otherwise Apple and Microsoft should be crazy to prefer it, don’t you agree?

    Plus, you need more hand gestures, more clicks to achieve simple task. Tabbed IMs? Tabbing could be great for web browsing, not for a multiple chat, otherwise all the most popular social networks whould be crazy to adopt separate IMs popups, don’t you agree? It’s paranoid to get used to something and don’t even try to update yourself. I mentioned just these few examples but there are more. When I joined SL, I wasted 2 weeks with V1 trying to figure the basics, and I gave up. When I switched to viewer 2, in less than a week I realized all the basics, and more. For oldbies of course it’s different, but the learning curve with the lastest viewer UI for new users it’s several times faster -and following the experience of users and new users I know- I have proofs of this).

Leave a Reply

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