Gavin Hird

I don't see any particular reason it would not be able to enter. It is already notarized and free apps is perfectly fine. Before you have made a test submission and looked at their response, IMO your take is simply an invalid assumption.

Do you?

Mentioning scalability; SecondLife is not very scalable at all, and that is perhaps the largest motivation for not making a mobile viewer. Imagine pushing a mobile viewer to the Google and Apple App stores, and have a few hundred thousand downloads all trying to log on to SL at the same time. The whole thing would immediately crash and burn, and the launch would be deemed a total fail.

That rumor has been attempted started before. – Hogwash! Opensim does not scale at all – there is not a single implementation that has concurrency over 500 users. In addition, it would be the Linux version Google would be interested in forking, and given its dependency on the dead end mono, they might just as well start from scratch and create their own virtual world environment.

The iPhone and iPad processors – which are pretty much identical to the desktop M1 and M2 processors in terms of single core performance will not have any problems running a natively compiled viewer. As they have fewer GPU cores than the M1 and M2, they will not be able to achieve the same graphics performance, or support as large screens when driving an external display, but they will have no problems running it. There are plenty of gaming titles that runs these mobile processors at full blast, yet thermal issues are never reported for these devices. The culprit is or course that on the M1 and M2 processors the viewers are running Intel versions translated to Apple Silicon at first launch to run under Rosetta2. – Rosetta2 does not exist for anything but macOS, and is also using special instructions Apple added to their ARM processors to use Intel addressing modes, hence it is not available on non Apple ARM processors. To get at viewer running on Apple's mobile devices, and soon macOS, the viewer will have to be rewritten with Metal2 (or better Metal3) for the rendering, as there is no support for OpenGL at all on these devices. OpenGL support will also be removed from macOS at the time Apple removes their last Intel machines from marketing (Mac Pro and one specific config of the Mac mini). It looks like the time for this will be the second half of 2023. The delusion that exists in the Lab and some of the TPV community that one can make a viewer with Vulkan for Apple's devices is just that: A delusion and a fast track to no Mac support at all.

If it was your sounds (as in you created them), you should already have a backup of them, right?

The package manager on Raspbian OS is apt. If you have anything else, get rid of it.

The mono issue is that a) After Microsoft took over the mono project they basically froze it in place. There has since virtually been only a minor update that Microsoft needed to make Visual Studio for macOS work on macOS 12.3 or higher on Intel. VS on Apple Silicon (64-bit ARM) ran under Rosetta2 translation. b) Microsoft has since release Visual Studio 2022 for Apple Silicon without mono, but rather native .NET6 support. The implication being they never supported mono on 64-bit ARM and never will. c) The situation for mono on Raspbian OS is that the previous version based on Debian 10 (buster) has support for mono up to version 6.12. This version of Raspian OS exists as 32-bit only. Raspbian OS has since been updated to be based on Debian 11 (bullseye) and only this version has a 64-bit version in addition to the 32-bit version. The 32-bit version can be coerced to install the buster version of mono 6.12, but Raspbian OS is shipped with mono 5.11 only. That 5.11 version has both 32 and 64 bit support. I don't know if Radegast will run on mono 5.11, but current versions of opensim won't. If you try and add mono 6.12 support to the 64-bit version of Debian (both Intel and ARM) or Raspbian OS by downloading the source and compiling it, it will install, but some of the development tools are missing. For opensim it means that it will no longer compile on Debian 11 (64-bit Intel or ARM) or Raspbian OS (64-bit ARM) with a mono 6.12 built for that system version. It also won't run even if compiled elsewhere and you have native built 64-bit libraries for ubODE and such. The 64-bit Intel version of Debian 11 can be coerced to install the buster version of mono 6.12, and it will then both compile and run opensim. Obviously with mono being frozen by Microsoft without an update for 2+ years, the entire mono environment will increasingly get flaky and eventually fall apart on new versions of operating systems it once was supported on.

I have both 2, 4 and 8 GB Model 4B purchased between since it was immediately launched and up to last year, and the base spec and processor has not changed during those years. The only change has been small revisions, one of which cause the processor to default to running at 1.8 GHz rather than 1.5 GHz on the 5.1.x kernel. For the entire lifetime of the 4B models you have been able to load a 64-bit kernel. Raspbian OS 64-bit version was in beta for almost 2 years, but it could be loaded on all 4B models ever sold by the RPI foundation.

If they have that processor and are only 32-bit they are fake! Official spec here: https://www.raspberrypi.com/products/raspberry-pi-4-model-b/specifications/

If you have Raspberry Pi 4B with ARMv7l you have been conned. The Raspberry Foundation has only issued Pi 4B with 64-bit processors. Install neofetch and see what it reports. A real 4B will report something like this (this one has a 32-bit system running on the 64-bit kernel because there is no reliable 64-bit mono for Raspian OS that will compile opensim): OS: Raspbian GNU/Linux 11 (bullseye) aarc Host: Raspberry Pi 4 Model B Rev 1.4 Kernel: 5.15.33-v8+ CPU: BCM2835 (4) @ 1.800GHz Memory: 641MiB / 7811MiB

Is there a link to the install instructions for an SL TPV viewer on a RPI?

On macOS, application output (even at fullscreen) is composited to the desktop at 60 fps regardless of how many fps the application is capable of generating or generates. If the viewer generates more than 60 fps, you will see tearing when panning the scene. So right now Mac users better keep vsync on. In the upcoming macOS 14 (Ventura) Apple supports monitors that can vary the frame rate between 3 and 120 Hz, which will be used on their portable HW to conserve battery (also in iPhone and Apple Watch for always on display support). The effect of this is that the viewer code for vsync no longer works on Ventura and the viewer will run at the fastest frame rate the HW can generate. The current desktop compositor in macOS is written in Metal 2 and the Metal version was first introduced in macOS 10.11. The original Metal implementation was flaky in that it allowed games and also the viewers to interact directly with the OpenGL HW in the machines, resulting in them overwriting GPU memory that the Metal compositor used and therefore crashed the GPU. This was only completely fixed/blocked in the macOS kernel in macOS 12.6, and is the reason why it is an exceptional bad idea to build the viewer with deployment target of less than macOS 11.13. The Ventura compositor is written in Metal 3. On Windows, that does not have the double buffer output and OS level desktop compositing of macOS, this obviously works different.

I posted updates that have the new profiles released in the SL 6.6.3 viewer in addition to all changes from the SL performance viewer merged. Since the SL performance viewer was the merge from hell, there are some features from the previous builds missing and it is not as snappy as the previous builds, but it performs quite a bit better in scenes with many avatars. YMMV The features will be added back + tricks up the sleve to get the snappiness back in upcoming builds. Not convinced the new profiles floater is quite the ticket... The Windows version is now built with Visual Studio 2019 (was 2017).

Not sure exactly what you mean by that – it is relatively identical to the LL viewer build system with the exception I have been lazy and still use autobuild version 1.0 There are a number of code changes to make it build the Intel version on Apple Silicone on Xcode 13.4.1 on macOS 12.5.1. I have yet to test building on Xcode 14 beta. Viewer seems to run fine on Ventura developer betas, but the code that LL added recently for vsync does not work any more, because Apple now supports displays that dynamically set the refresh rate between 3 fps and 120 fps depending on what is displayed on the screen. The viewer runs as if vsync is turned off on Ventura.

I'd be interested know if you use the World>Chat Bar... or Avatar>Conversation (commando+T) when you experienced chat slowdown? Dayturn does not have moonwalking, true. It does have Area Search at World>Area Search. I also have not published the RLV version as, frankly, it is a PITA to maintain and test for someone who have no interest whatsoever for the feature.

UI lag bug? – Please detail.

Better that than the fan-***** of Firestorm! 🤪

The latest Firestorm should be notarized, meaning there should not be any issues from the Apple side of the equation to download, install and run it. There might of course be other issues with their code that blocks it from running on M1/M2 processors. You can try my Dayturn viewer builds, which are signed and notarized with my Apple developer ID. In addition it has a number of updates to the code to make it more compatible with newer version of macOS. It is also built with the latest Xcode on a Mac with M1 processor and verified to run under Rosetta2 on Apple Silicon. You can download the preview version from here.

No, you subscribe to system events such as applicationDidReceiveMemoryWarning (UIKit on iOS) and DISPATCH_SOURCE_MEMORY_PRESSURE with the event flags: DISPATCH_MEMORYPRESSURE_WARN, DISPATCH_MEMORYPRESSURE_CRITICAL and DISPATCH_MEMORYPRESSURE_NORMAL. You don't monitor every malloc(), which in macOS you don't really have full control of anyway.

I know, but a properly coded Mac app does. The SL viewer is a hack from that standpoint too.

No, on macOS where GPU RAM = system installed RAM you only need to make normal requests to the operating system to fulfill your memory request, and leave it to the operating system to handle it, even if the system need to swap to fulfill your request. You only need to handle low memory situations as signaled by the operating system, and reduce your memory requirements which can be done by flushing caches, temporarily turn off features like shadows, ALM and so on. If you run out of options to reduce your memory consumption and the system still signals you are in a low memory situation, you terminate gracefully. Of course you need to make sensible request to how much memory you allocate, meaning you request less GPU memory on a machine that has 8 Gb system memory compared to a machine with 64 Gb system memory. Consequently you set your texture memory limits accordingly. For the Mac models with Intel processor it is pretty simple to set some general rules, because Apple has been consistent with how they equip their machines with VRAM. All Intel based portable machines and the Intel based Mac minis supported by macOS 10.14 or higher, have Intel integrated graphics with 1536 Mb graphics memory. So you only need to check for the presence of Intel graphics. For all stationary Macs with Intel processor having AMD graphics cards and supported by macOS 10.14 or higher have a minimum of 4 Gb graphics memory. All Macs with Apple Silicon support as much graphics memory as there is installed system RAM, which is minimum 8 Gb. No machines supported by 10.14 or higher have NVIDIA graphics cards. If you set your deployment target (minimum system requirement) for the viewer to 10.14 or higher, you know that you will not meet systems with less than 1536 Mb graphics memory and you can set the defaults accordingly. If you run on a machine with Apple Silicon you know you can safely allocate 2048+ Mb graphics memory. You can safely do the same on a system with AMD GPU (up to 4 Gb).

macOS (and not OSX) does not really give you any tools for how much VRAM is available, because all new Apple systems in marketing have unified memory where the CPU and GPU share and allocate the same memory. So depending on your system configuration, the GPU can allocated close to 120 GB memory if it wants to in a system with 128 GB main memory. The above also means that the GPU allocated memory is subject to system paging, which in theory could overcommit GPU memory used by all applications running on the system. What Apple programming guidelines advices is for the application to subscribe to a low memory system events and act accordingly to either reduce memory use or gracefully terminate. Because of other issues with the viewer code subscribing to such events are really not possible...

If it is such BS, why don't you whip up the code and show the rest of us how its done? – Windows and macOS.

Virtual Private Relay does NOT corrupt the macOS filesystem, but the viewer will probably not work as intended if you obfuscate the address it logs on from. Turning off Virtual Private Relay will again send your address information correct to the SL servers, so it can properly communicate with the viewer. There is also a possibility that Virtual Private Relay does not handle UDP correct (if at all), meaning packages from the server never reach your viewer subsequently leading to failure. While most of the communication now goes over http/tcp the viewer still use UDP for certain functionality.