Re: [opensource-dev] Replacement for QuickTime media plugin - a straw man proposal

. Equivalent is probably the case for Windows, while for Linux there landscape is much more complex. Geir Nøklebye ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before

[opensource-dev] Replacement for QuickTime media plugin - a straw man proposal

For OS X save yourself all the trouble in the world by using the OS X media frameworks and QuickTime. To create a 32-bit OS plugin based on LibVLC just to covert it to 64-bit is asking for trouble and weeks of headaches when you already have everything your need both for 32 and 64 bit QuickTim

Re: [opensource-dev] Replacement for QuickTime media plugin - a straw man proposal

Which is absolutely true but nobody suggested to use Carbon in the 64-bit continuation, but the relevant frameworks. For all we know it may not even be possible to compile or run the viewer any more on OS X 10.12 or whatever they will call it (WWDC 2016 ) with the current codebase. First step

Re: [opensource-dev] Quicktime on Mac

videos/play/wwdc2016/405/ <https://developer.apple.com/videos/play/wwdc2016/405/> Cheers, Geir Nøklebye > On 15. jun. 2016, at 21.00, opensource-dev-requ...@lists.secondlife.com wrote: > > Send opensource-dev mailing list submissions to > opensource-dev@lists.secondlife.

[opensource-dev] About memory management on macOS 10.12 (Sierra) potentially affecting all viewers

) Cheers, Geir Nøklebye ___ 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

[opensource-dev] About memory management on macOS 10.12 (Sierra) potentially affecting all viewers

occ/cl/NSAutoreleasePool So all this code needs to be rewritten to support ARC or it will not run or fail on 10.12. Geir Nøklebye,___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the po

[opensource-dev] About memory management on macOS 10.12 (Sierra) potentially affecting all viewers

thread autoreleasepool In fact the above is a classic example of the old garbage collector in action. Geir, > On 8. jul. 2016, at 21.47, Geir Nøklebye wrote: > >> Cinder Roxley said: > >> The viewer has never used the garbage collector so it?s not an issue. > &

[opensource-dev] About memory management on macOS 10.12 (Sierra) potentially affecting all viewers

To all your nay sayers, just try to compile the viewer with the -fobjc-arcflag that is the default since OS X 10.8 and see where that gets you. I also sugget you read the migration guide: https://developer.apple.com/library/ios/releasenotes/ObjectiveC/RN-TransitioningToARC/Introduction/Introduc

[opensource-dev] About memory management on macOS 10.12 (Sierra) potentially affecting all viewers

In comment to Geenz Spad 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

[opensource-dev] About memory management on macOS 10.12 (Sierra) potentially affecting all viewers

Apple is pretty predictable in how they announce changes to their code. Every summer, at the WWDC, they announce a slew of changes that will be introduced throughout the next year. They also announce deprecated technologies, which usually takes 3-5 years to completely be unsupported. They also

[opensource-dev] About memory management on macOS 10.12 (Sierra) potentially affecting all viewers

I said long term, and by long term I mean 5-10 year horizon. For an operating system that is closing in on 35 years of existence, that is a reasonable timespan. ;-)) System 10 (OS X, where X is the roman numeral 10) is now 15 years - 2 years more than SecondLife has been around. During that t

[opensource-dev] About memory management on macOS 10.12 (Sierra) potentially affecting all viewers

The viewer does not build unless this flag is turned on. It hasn’t for a long time. > On 10. jul. 2016, at 11.09, Nicky Perian wrote: > > Does LL client also crash when built with suppress warnings of deprecations > flag on? > > On Sun, Jul 10, 2016 at 1:07

[opensource-dev] Mac viewer and Apple maintained opensource libraries

ibs in /System/Library/Frameworks/ApplicationServices.framework/Frameworks/ImageIO.framework/Resources/ Cheers, Geir Nøklebye aka Gavin Hird___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please re

Re: [opensource-dev] Mac viewer and Apple maintained opensource libraries

Some are outdated and some are more up to date than the current viewer libraries. They usually get serious amount of public flack if security issues are not fixed, meaning they are automatically patched when users upgrade their systems. • The other thing is they are all compiled both 32 and

Re: [opensource-dev] Mac viewer and Apple maintained opensource libraries

Cinder said >For what it?s worth, Apple did warn developers to stop using it and switch to >Cocoa?s crypto frameworks or ship their own. …and that is the core of the state of the macOS version of the viewer(s). Deprecated code all over. When will be see the crash in the occlusion code being

Re: [opensource-dev] Mac viewer and Apple maintained opensource libraries

Dahlia Trimble said: > It's probably considered bad practice for code to use an ARB extension > without first checking to see if it's available. All the viewers already detect and log this, and you will find it at asa log entry like: 2017-02-01T08:08:30Z INFO: #RenderInitinitExtensions: Could

Re: [opensource-dev] Mac viewer and Apple maintained opensource libraries

Cinder said > It's not a viewer bug, it?s an issue with Apple's Nvidia driver. (also note, > that it doesn?t happen with Radeon or Nvidia?s own driver, just Apple?s and > happens to hundreds upon hundreds of games available on Steam.) Apple Software Engineering has acknowledged that such crashe

Re: [opensource-dev] Mac viewer and Apple maintained opensource libraries

Whirly Fizzle said: > Switching over to using the Nvidia web drivers fixes the frequent crashing > but some systems suffer poorer viewer performance with the Nvidia web drivers. You can use the so called NVIDIA web driver as it gives the current viewer code access to the direct hardware address

Re: [opensource-dev] Mac viewer and Apple maintained opensource libraries

Oz Linden said: > If you've got a fix, we'd love to see it. There is no quick fix except rewriting the renderer to use the NSOpenGLProfileVersion3_2Core profile or even Metal (which would also be a first step to also run on iOS). In Kokua we have managed to delay the crash from happening withi

Re: [opensource-dev] Mac viewer and Apple maintained opensource libraries

This is the typical anatomy of the crash that accompanies the GPU reset. It also crash even if you turn of shadows and ambient occlusion, but then with much lower frequency, Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 com.apple.GeForceGLDriver 0x906aeb6c 0x9037e000

Re: [opensource-dev] Mac viewer and Apple maintained opensource libraries

Henri said: > Meaning you actually didn't fix anything... > Stupid question: what happens if you disable the Objects occlusion setting in the graphics preferences ? The root cause of the problem is not fixed, no. It put some bandaids on it to reduce the crash frequency. The autoreleasepool issu

Re: [opensource-dev] Mac viewer and Apple maintained opensource libraries

@Cinder With reference to Xcode 8 release notes, section Deprecations it reads: OS X 10.11 was the last major release of macOS that supported the previously deprecated garbage collection runtime. Applications or features that depend upon garbage collection may not function properly or will n

Re: [opensource-dev] Mac viewer and Apple maintained opensource libraries

Cinder wrote: > Enjoy spamming the list and pulling our changes. :) Elephant in the china store much? Of over 38000 commits in your own viewer your contribution is 680. So where are you pulling the rest of your changes from? We all owe a massive Thank You! to Linden Lab for these alternati

Re: [opensource-dev] macOS Catalina notarization

It is not only that you have unsigned libraries, but there are two other issues: 1. The Chromium Framework is not correctly structured, but must have the structure described in https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/FrameworkAnatomy.htm

Re: [opensource-dev] macOS Catalina notarization

When it comes to deployment target, I see that in https://bitbucket.org/lindenlab/build-variables/src/master/variables which I suppose is the latest build variables used, you build with deployment target of 10.7 and with th