Look, Geir, not so many years ago the now-deprecated and soon defunct garbage collector was the new hotness. If we'd followed the course you're suggesting now, of always switching to Apple's latest APIs, we'd really be in a pickle now. On Jul 9, 2016 8:58 AM, "Geir Nøklebye" <geir.nokle...@dayturn.com> wrote:
> In comment to Geenz Spad <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 >
_______________________________________________ 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
