I'm hearing shouts of "We want Display Postscript!" from below the ramparts.
I usually hear "Oy.. watch where you're chucking your rubbish, we're trying to sleep down here" from below the ramparts..
@Sam R Make jokes all you like; I am pissed. I found out the hard way that I've cut down my potential customer base by (possibly) half. Because Apple broke OpenGL in 10.14 and are removing it in 10.15.
I feel your pain and my list of RADAR reports marked as "Not a bug, that's the way it's always worked and what the users expect." make me wish that I could simply pull the plug on our macOS offerings.
My favorite right now is the "Full Disk Access" debacle and the white listing not supporting non-bundled console tools or daemons. The only solution is to have the customer disable SIP. This new "feature" implementation occurred between the last betas and the GM (again), so we had no idea that it was coming until it bit us at customer sites.
Sorry, if we appeared flippant.
Seconded. We feel your pain. Especially given that you're one of our 'key people'
In smaller ways, Apple's changes generate issues for me with nearly every release.
Even Dark Mode has cost me months of (to me) pointless work.
Apple broke OpenGL in 10.14 and are removing it in 10.15.
Instead of fixing it, or reverting the changes, and then just leaving it alone for people who want to use it, (while encouraging the use of Metal.)
Thats the thing that gets me.. there is no need to take it away
It's not like they are short of disk space.
Maybe this is another early sign of moving to ARM.. remove OpenGL and they don't have to recode that bit?
@Beatrix W You know you should have tested this before development.
Agreed; I let my frustration with Apple cloud my judgement. I was so miffed that they broke OpenGL in Mojave, I incorrectly assumed that as 10.11 supports Metal, all the machines it runs on also supports Metal.
@Tim J make me wish that I could simply pull the plug on our macOS offerings.
You, I and many macOS developers feel this way. The annual updates with a general lack of care have helped to eat away at Apple's "It just works" reputation. They do themselves no favors with their current hardware either.
@Jeff T In smaller ways, Apple's changes generate issues for me with nearly every release.
This is how a lot of developers feel, so much work, just to keep the app alive, which takes away time from being able to make the application a better product. It's infuriating.
@Jeff T Maybe this is another early sign of moving to ARM.. remove OpenGL and they don't have to recode that bit?
Technically they already have it for ARM, as it was also in iOS. However they've removed it from there also. My feelings on why Apple it removing so much stuff from the OS, is to reduce the workload for the engineers, so that they can reduce the amount of engineers and therefore save costs, and increase ROI.
@ChristianSchmitz Why not use higher level framework like SceneKit?
Because I am not using OpenGL/Metal for 3D scene rendering. I am using it/them as a rendering destination for Core Image, which gives incredible onscreen performance increases.
For the time being, I've cobbled together a new canvas subclass that uses CALayers, when OpenGL is selected it creates an CAOpenGLLayer and when Metal is selected it creates a CAMetalLayer. If Metal is supported, it uses Metal, otherwise OpenGL. They're not directly compatible, so I've duct taped some bridge code so that can at least both draw. I've removed some functionality, I may add it back in the future, once I can figure out a solution for both.
I've also reverted my kernels to use GLSL (as this works on both, for the time being) instead of MTSL.
Hopefully today or tomorrow I can send this out for testing.
Do you want to know something funny? Our much earlier apps; which are pure Xojo & Einhugur picture effects, compiled as 32-Bit CARBON applications (back last decade), still kinda work in Mojave (although not always). Yet an app I wrote last year, using Apple's image editing API stopped working when Mojave was released. Seems like the moral here is to avoid using Apple's fancy APIs!
I hope you didn't use any intel optimize threading or SIMD / MMX dependant calls.. like OpenCV...
I hope you didn't user and nVidia optimized parallelism like CUDA...
I hope you didn't think cross platform would live for very long....
It's just time we developers said no to this...
In the mean time.. what about Vulkan?
@Brian O'Brien I hope you didn't think cross platform would live for very long....
It's just time we developers said no to this...
That's the painful irony here, as I didn't go x-plat with this project. I am just targeting the macOS, but with Apple's rabid rate of change (I swear some of it is simply for changes sake), it's becoming almost impossible to rely on using Apple API for more than a couple of versions of the macOS.
@Brian OBrien In the mean time.. what about Vulkan?
Sadly Vulkan isn't supported by Core Image. Although if I'm honest I do question how long Apple is going to support Core Image.
It's apparent now that I cannot trust Apple to not break things in the future, and therefore I need to come up with a solution whereby I use as little of their stuff as possible, this would also help to open it up to becoming an x-plat application. Which I think is going to be more critical in future.
I primarily used TurboForth for the TI-99/4A and JForth on the Amiga. Forth was so much more productive than TMS ASM. The TMS9900 was on par with the later Motorola 68000, but had far more extensible features - Need a new set of registers - create 'em. Too bad TI botched that chip. I'd love to see where that architecture ended up by modern standards.
Forth was awesome. So was the amiga.. 68000 architecture.. Motorola. Big Endians.
It's about time the industry had a bit of an upheaval..
I feel like we haven't moved passed the 386, all we have now are cores of these older processors.
Anybody remember Occam and Transputers?