Oz Linden starts off the Third-Party Dev UG meeting by saying there isn’t much new to talk about. ‘New’ is obviously a relative-subjective term in Oz’s use of the word. See if you learn something new about what is going on. I did.
Alex Ivy, the 64-bit viewer, failed its recent QA. A fix and retest is expected to happen early next week with an update to appear then.
Errors came from refactoring the launcher code. Just a couple of new bugs held back the release as the Lindens wanted to fix them before release. One problem holding back Alex is the unreliable crash reporting. Sometimes crashes report and sometimes not. Oz says they are working full time to get that sorted.
The Voice RC has gotten an update which is still in QA. When it passes QA we will see the new version out.
A new Maintenance branch will appear in RC about the middle of week 35.
The Lindens are thinking they will soon block a number of older viewer versions. It has been a while since they pushed older Linden viewers off the grid.
Last Tuesdays’ system problems provided some good testing of recent changes. There is still lots of background updating going on, hardware, web sites, place page fixes, simulator operating systems…
Grumpity Linden says they are moving back to working on Estate Tools. No clear ETA. Possibly better ban list management will be in this round of changes or follow quickly. Programmers were pulled off the tools to work on crash fixes.
Texture limit memory is being increased. I think this should reduce texture thrashing problems (render clear, blurry, clear… repeat).
Lindens are optimizing the cache and collecting more stats for cache performance. They feel several cache issues need attention. Oh yes…
If you are curious how well your cache is or isn’t working, open you Viewer Stats panel (Ctrl-Shift-1). Expand the ADVANCED section by single-left-clicking. Expand the Texture section within ADVANCED. You’ll see Cache Hit Rate, Cache Read Latency, and six more metrics. The best cache size is the maximum possible.
Cache Hit Rate and Cache Read Latency are newer additions to the Stats panel. The Hit Rate is the percent of files being found per second, I think ‘per second’. So, higher numbers are better. When you are in your Home you should see high numbers. Don’t be surprised if you don’t. And the ONLY things I know that you can do to improve the numbers are to reduce draw distance and increase cache size.
Read Latency is, I think, mostly a matter of your computer’s ability to move data around. As best I can tell it is a combination of downloading, caching, and delivering items to the viewer.
Placing the cache on a faster drive should reduce this number. But, memory speed, the actual capability of the memory chips, will have an effect too. Also, other traffic going and coming from the drive will slow things. Have your Windows and viewer caches on different drives.
Smaller caches have higher latency and lower hit rates. Using a smaller cache (2GB) on a fast RAM Drive gives worse numbers, hit and latency, than my large cache (9GB) on a slower SSD. So, cache size looks to be the most significant factor in performance.
One thing that will happen in the near future is the cache size will get bigger, meaning a higher size limit. I guess I will need a bigger RAM Disk.
The larger cache is needed as the file format of cached files is going to change. As it is now the coded (compressed?) version of the JPG2000 file is cached. When the file is used it has to be decoded. To speed up image /texture loading the decoded version of these image files will be cached. The files are larger and so it requires larger cache.
KDU versions are going to be important for handling the decoded cached files. If you don’t know KDU is short for the Kakadu Software made by a third-party that handles the JPG2000 format images.
So, when a viewer changes KDU version or a user switches their viewer from 32 to 64-bit, the cache will be flushed. Theoretically, it shouldn’t be a problem if the KDU version changes. But, back in the day when all viewers shared a single cache we had a load of problems thought to be from different packages and versions handling cached texture files. Users began assigning separate caches to each viewer brand and their problems stopped. Soon separate caches became standard in viewer design.
The Lab updates KDU about 2 times a year.
Also, the Virtual File System (VFS) is being looked at. It may go away as there doesn’t seem to be that much performance gain with it. A reason to remove it is there are possible stability issues and size limits associated with its use.
The inventory is getting work too. Whether users will see changes (like they’ll do something different or have a new feature) is doubtful. Sort of like getting a new kitchen garbage disposal. It is better but the same.
There is a Maitreya issue people are running into. The Lindens have nothing to go on for tracking the problem down. They are looking for a way to catch the problem in action. BUG-10515 – Unable to rez object because its mesh data is invalid. In this case, it is a matter of the region thinking the mesh data is invalid. The data in the asset server is OK. So, the mistaken region creates the problem by popping the bogus error message. Sort of fake news.
This isn’t a Maitreya specific problem. The high-poly-count body is popular and those using Maitreya are more likely to see it, thus the name.
McAffee anti-virus and MalwareBytes errors are popping for some viewer users. Some technical thing involving Internet security. The Lab needs a way to reproduce the error to get started fixing it. People are seeing the error on Firestorm 32 & 64 and Alchemy 64. Elder Scrolls users are seeing the same type of error too.
Another problem is Attachments failing off on region crossing. This is on the list things to be fixed. The problem has been researched and a fix-it-plan decided on. It is a large project. So, it will be a while before we see it fixed.
The Lab is doing quite a bit. New stuff is on the way and a lot of behind the scenes improvements. What we call ‘new news’ is debatable.