Kokua and Black Dragon go 64-bit in Second Life

As the Lab’s 64-bit Alex Ivy viewer progresses through release candidate stage and the point where the code is regarded as a stable enough for TPVs to start picking up, viewer developers having been doing just that.

First out of the v5-stage gates at the start of September was Nicky Perian with 64-bit versions of Kokua for Windows and Mac. Towards the middle of the month, NiranV Dean issued a 64-bit version of Black Dragon for Windows.

It should be noted that in neither case are the provided 64-bit viewers the final, polished article. Nicky has clearly labelled his versions as test releases, which Niran is referring to his as an alpha series of releases.

I’ve not driven either viewer to any great extent, so the following is more informational than anything else. Please refer to the links at the end of this article for all download links to the viewers.

Kokua 64-bit

The Kokua 64-bit builds come in both RLV and non-RLV versions. Each is functionally identical to the other, with the exception of … RLV inclusion.  For convenience, I downloaded the 64-bit Windows version with RLV. all of the versions are based on the Lab’s Alex Ivy code base.

The Windows viewer builds include the SL Launcher .EXE, designed to ensure the correct version of the viewer (32-bit or 64-bit) is installed on your PC when updating the viewer. However, at this point, neither actually utilises it directly: the installation short-cut for the viewer points directly to the viewer .EXE. As the Launcher is also intended to start / terminate the viewer’s crash logging, and given – if I recall correctly – Kokua utilises the Lab’s viewer update process, I assume use of the Launcher may / will be folded-into the Kokua’s 64-bit Windows flavours in the future.

Beyond this, the viewer is functionally identical to the last full release of Kokua (, with additional updates from the more recent LL viewer releases since that date. This means the 64-bit viewer now includes the Asset HTTP updates from the Lab and the current release version ( I understand the 32-bit versions of the viewer have also been merged with these updates, but have not been formally released.

Nicky does note that there are some issues with the Mac 64-bit version of the viewer, some of which prompted an update following an initial release of the test viewers. Some of these have been logged via JIRA with the Lab (such as BUG-41395). For those downloading and trying the viewer, he particularly requests that feedback be given on notifications and taking / processing snapshots, which have caused noticeable issues in merging the code (obviously, feedback on other aspects of the viewer and problems encountered is also welcome).

Black Dragon 64-bit

Black Dragon currently has the SL Launcher removed. This generates a warning on starting the viewer, advising users to run things from the Launcher and to update short-cuts accordingly. However, it doesn’t interfere with the viewer’s operations.

The 2.9.0 64-bit version incorporates Niran’s more recent updates up to his 32-bit 2.8.2 release. For those with hardware which can handle it, Black dragon continues to offer a graphics experience several points above other viewers. For some people, this is somewhat mitigated by the viewer’s menu system presentation, which can take a little getting used to but really isn’t that hard to steer around. The large number of graphics options exposed / added can be a little frightening to those not into graphics tweaking – but again, there’s no real need to play around with any you’re not familiar with when adjusting settings.

In addition to the 64-bit iteration, the viewer includes further refinements to SL shadows, including an attempt to deal with a particular annoyance for photographers: disconnected shadows. That is, shadows which just fall short of actually visually connecting with the object casting them, and which at time no amount of jiggling with settings such as shadow quality and/or shadow bias can fix. A further change is that HTTP pipelining has been disabled within the viewer.

Rough-and-Ready Performance Notes

The benefits in using 64-bit versions of the viewer – for those who can – are much better memory utilisation and potentially a reduced crash rate and, potentially, a boost in overall viewer performance. In terms of the latter, and while direct comparisons are always subjective (and dependent upon some factors outside of your control, such as the complexity of any other avatars in your field of view / in the region, etc), I carried out some very rough-and-ready tests using ~Neive~ as my testing-point, and with the viewers all set-up according to my review system specifications.

Baseline test location: ~Neive~ 199, 155, 27, facing west, with three (or in the case of the Black dragon 32-bit version test, four) avatars within draw distance. All measurements were taken after setting the preferences in each viewer, and clearing object and texture caches before doing a fresh load to ensure each viewer had the scene locally cached. I then launched each viewer in turn, let the scene load from cache, measured, shut-down and launched the next & repeated.

FPS Static FPS panning left / right
Firestorm 64-bit 25 22-28
SL Alex Ivy 38 33-38
Kokua 32-bit 23 20-23
Kokua Alex Ivy 37 34-37
Black Dragon 32-bit 2.8.22 36 33-38
Black Dragon 64-bit 2.9.0 Alpha2 45 33-46


  1. Firestorm 64 is currently not using the Lab’s 64-bit code base, and so might be considered an indirect comparison, rather than a like-for-like code base comparison.
  2. Black Dragon has many additional exposed / tweaked graphics options, and a number of defaults somewhat different to the default viewer. In measuring, I attempted to tweak the viewer back more towards the default viewer.

Also note that the static fps numbers are a median based on fluctuations in numbers; the panning figures represent the average high/low fps values when panning. All measurements taken via the Stats floater (CTRL-SHFT-1) to ensure consistency of displayed floaters in the viewer.

As indicated towards the top of this article, I’ve not really played that much with either viewer, so cannot comment in-depth on overall performance  / stability, etc.

Links and Downloads

4 thoughts on “Kokua and Black Dragon go 64-bit in Second Life

  1. Interesting benchmarks. When it comes to viewers, as a Mac user i find performance greatly different, for instance the Mac version of AlexIvy does not even support Advanced Lighting and shadows yet. Im more frightened that Linden Lab will one day just stop supporting Mac because they find it too difficult, than i am of any new VR Platform coming along to replace SL.


    1. Yeah, the ALM issue is noted in the bug report I’ve referenced. The benchmarks are obviously a broad thumbnail and almost entirely subjective (we all have other apps running when using SL, so these might have an impact as they chew on CPU time, etc), everyone’s network connection is different (although I tried to eliminate this through the “pre-loading” of the scene to cache), and so on. We all also have other tweaks and adjustments in the viewer which may affect things as well – but at least they give an idea.

      It’s hard to say on viewer support. Windows represents the vast majority of users (around 93-94%?), but Mac users are probably of a volume (5%-ish?) that it is worth support continuing – particularly as there are Mac users at the Lab and there’s a good pool of developers. The major reasons given for LL backing away from dedicated Linux support were user volume (only around 1% of users) and an apparent difficulty in recruiting a dedicated Linux desktop developer.


    2. They have already dropped support for Linux. They still have a 32-bit viewer, but it doesn’t work for me. I have been using 64-bit software for around fifteen years, and I must admit to a certain weariness over the persistence of 32-bit. Firestorm and Cool VL Viewer work as 64-bit. That comparison shows that Firestorm 64-bit uses a huge amount more RAM than Cool VL Viewer, and in my experience Firestorm is marginal in 4GB of RAM (Don’t forget you need the OS too.)

      I wonder how much some of the code in AlexIvy has had to change, how it compares to what Firestorm did, and whether Firestorm will improve when a merge is done. (Assume AlexIvy is still very new when the next Firestorm version appears.)

      I have a suspicion, generally, that a lot of software today is being written and maintained by people who haven’t needed to care about memory use. At times, I have wondered if Firestorm was loading data from cache and promptly putting it in the virtual RAM. Certainly, Firestorm can struggle with crowded sims, and it was soon obvious that Cool VL Viewer was a better choice for visiting SL14B.

      I wonder if we Linux users are really so rare. I started with a TRS-80. Now that was unusual. Businesses were still using mainframes.


      1. “They have already dropped support for Linux. ”

        The Lab ceased active development of the Linux flavour in May 2015, requesting open-source contributions to keep the viewer updated. However, as Oz has indicated, and I’ve reported (numerous times), the Lab *is* re-working their Linux viewer build process to make it easier to produce a more readily distributable Linux viewer – *contingent* upon getting input from Linux developers.

        Alex Ivy utilises a revised build process, utilising 64-bit libraries, etc., for the 64-bit built (and the existing 32-bit Libs for the Win 32-bit build). Firestorm are currently working on revising their 64-bit version to utilise the 64-bit code from the Lab.

        “I must admit to a certain weariness over the persistence of 32-bit.”

        The Lab’s plan is to have 64-bit for Mac and Linux (again, contingent upon open source contributions). 32-bit is to be maintained for Windows simply because of the number of Windows users who are still on 32-bit versions of Windows.

        “I wonder if we Linux users are really so rare. ”

        In terms of SL, and according to the available stats – yes. As far as I can recall, Linux has only accounted for around 1-2% (most of the time it’s been pegged at between 1-1.5%) of the overall log-ins.


Comments are closed.