In comment to Geenz Spad <ge...@exodusviewer.com <mailto:ge...@exodusviewer.com>>:
There is much more to it than the knee jerk opensource community reaction of resisting to "Apple made it the default for new projects, so you should too!” By migrating the code to to the Apple defaults makes the code much more portable across macOS system versions and often ensures that the code runs with few or no modifications even if Apple makes big breaks to the underlying system software or even hardware. Having worked in Apple Product Management I have seen it over and over again that developers who fail to maintain their code according to the Apple guidelines suffer badly when Apple does something “unexpected. Very good examples of this is the disaster that Microsoft Office has been on macOS for years, as also is the case for almost the entire Adobe product suite. Others are using QT that often result in sub par experiences both for developers and users. Many of these applications simply vanish from the market as the developers are not able to move the application forward. One such example of an “unexpected” change is the introduction of Metal, where the viewer rendering code has not been changed for this fact resulting in a GPU crash on any version of the viewer when running on macOS 10.11. (regardless of LL or TPV developed.) The GPU crash has been both acknowledged by Apple product development and by LL, but the LL code needs to be fixed for it to work. This crash is clearly related to memory management both on the GPU and on the main system. (NVDA(Graphics): Channel exception! Exception type = 0x1f Access Violation Error (MMU Error 2)) It happens because macOS 10.11 use Metal for compositing the desktop so memory usage has changed. Installing NVIDIA’s driver removes the crash, but it results in a loss of typically 10 fps for the viewer. By acknowledging that a macOS application is distinctly different from the standard C++ application, and structuring the code for the macOS version thereafter, one would not only do everyone, including LL, a favor but it would also make the path for a viewer running on iOS devices much shorter. It would improve performance, give macOS users access to system services they find across their application portfolio, and would make development more consistent and reliable. It would possibly also reduce the number of issues reported to the LL service desk and improve retention for new signups. I’ll have macOS 10.12 beta 2 installed today and see how the viewers run, but on beta 1 only one of all the tested viewers ran (still with crashing plugins.) One popular viewer compiled with the old GCC could not start at all. My intention is to remove all the code that prevents compilation with ARC, acknowledging that MRC will still be needed for some interfacing with Foundation and C++. For the Renderer issue I am not in a position to fix the GPU crash. I have yet to confirm if this issue still exist on 10.12 as that requires a viewer that actually runs on it without one or more components crashing. TC, Geir
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
