3 ms·

I am not upset because Metal replaced OpenGL. I actually like Metal's design. What I am upset about is the removal of a standard that worked well. Just don't a

I am not upset because Metal replaced OpenGL. I actually like Metal's design. What I am upset about is the removal of a standard that worked well. Just don't allow OpenGL apps in the Store and that would be enough. Even worse, removal of 32-bit support in macOS. Now that's a extraordinarily bad move that confirms Apple does not care about enterprise nor gaming.

NobodyNada 7y ago
AFAIK OpenGL hasn't been removed, and isn't planned to be in the near future; it's just been deprecated. Apple isn't adopting new versions of OpenGL or Vulkan, but OpenGL code that used to run on macOS still runs on macOS.
- gdxhyrd 7y ago
  OpenGL support has been abandoned by Apple years ago, not to mention being broken. The fact that it is now officially deprecated is just a warning from Apple to remove it soon without bad PR.
  - xenadu02 7y ago
    You are moving the goalposts. You stated: > What I am upset about is the removal of a standard that worked well That is not correct on either count: 1) OpenGL is a terrible fit for modern GPUs so I don't agree that it "worked well" 2) OpenGL was not removed anyway > OpenGL support has been abandoned That is not correct. Code continues to be written and maintained to keep OpenGL working on newer GPUs, both OpenGL ES on iOS GPUs, as well as OpenGL on mac GPUs. > The fact that it is now officially deprecated is just a warning from Apple to remove it soon without bad PR. macOS/iOS continue to support /many/ deprecated APIs, some of which have been deprecated for over a decade. Contrary to popular opinion, things are not removed just for fun. Things are removed when there is a sound security/technical reason, or when there is a high ongoing cost either to end users or the development process. The alternative is to be MS and never remove anything, and where any changes to observable behavior of the system (or even moving internal struct values around!) can cause breakage and so is not done or requires inserting hacks to preserve behavior. If you think that doesn't impact individual engineer's decision making process ... well I don't know what to tell you. It must be soul-crushing to know if you change an internal data structure from uint16_t to uint32_t some crappy app that depends on being able to poke around will break. Surely such policies encourage some developers to do even more such hacky things, knowing MS will take the blame and end up making sure you can keep getting away with it.
    - saagarjha 7y ago
      > Code continues to be written and maintained to keep OpenGL working on newer GPUs, both OpenGL ES on iOS GPUs, as well as OpenGL on mac GPUs. Yes, but from the outside this is not necessarily obvious. Just ask the VLC developers: they’re running into breakage constantly on macOS. There were a couple of builds back in the summer where OpenGL just wouldn’t initialize at all, meaning even system components like WebGL, iTunes visualizers, and certain screensavers wouldn’t work correctly (though I did notice that there’s a new one written in Metal that wasn’t affected…)
    - pjmlp 7y ago
      > The alternative is to be MS and never remove anything, They do remove stuff, all the time, the transitions just happen to be a bit more gentle, with more years to prepare for it, although not always, e.g. 16 bit, MS-DOS support, WinG, WinRT (Win 8.x variant), WDDM, WCF, Remoting.
    - gdxhyrd 7y ago
      > You are moving the goalposts. No, I am not moving goalposts. OpenGL has been useless for all intents and purposes in macOS for years already. The deprecation is the least of concerns. > 1) OpenGL is a terrible fit for modern GPUs so I don't agree that it "worked well" A terrible fit? What are you even talking about? It is as featureful as the latest D3D11 which is the API most games are based on. What is useless is the OpenGL version and drivers that Apple ships. Please don't spread FUD. There are no security nor technical reason nor significant cost on maintaining a proper OpenGL.
eschaton 7y ago
OpenGL has not been removed from macOS though. It’s just been deprecated.
- gdxhyrd 7y ago
  See the sibling reply.
xenadu02 7y ago
> Even worse, removal of 32-bit support in macOS 32-bit macOS used a fragile ABI for Objective-C, meaning all ivars had to be in public headers and changing any of them changed the runtime layout of your class and _all_ subclasses. AKA adding a field was a breaking change. This imposed a huge maintenance burden up and down the stack. Often classes would include a void* pointer to a side-table where new fields could be added, or the public class was a wrapper around an internal implementation. Both of those have a performance cost (extra pointer chasing + extra mallocs, or double objc_msgSends for every method/property). There are many other performance optimizations (eg non-pointer ISA) that were impossible on 32-bit, meaning every app that refuses to move to 32-bit imposes even more performance costs. Shipping 32-bit versions of frameworks also bloats the size of the OS and forces the OS to load a duplicate dyld shared cache. It even makes system updates and installs take twice as long (two shared caches need rebuilding after all!) None of this accounts for future optimizations and improvements that would have been nearly impossible if the system still had to support 32-bit without forking half of the userspace frameworks... that kind of forking would be an absolute maintenance nightmare. The deprecation of 32-bit has been obvious for over a decade. It is based on sound technical reasons. You may not agree with those reasons but they have nothing to do with not caring. You might instead ask why a developer would choose to ship a 32-bit app/game anytime after 2010 when 64-bit was available and obviously the future? Should all Mac users continue to pay the cost in disk space, memory, and performance? How long should they pay that cost? Were you hoping macOS would support 32-bit applications in 2030? 2040? What about the undeveloped features and unfixed bugs due to the overhead of continuing to support 32-bit?
- tsimionescu 7y ago
  In an ideal world, 32bit would continue to be supported for as long as people use 32bit applications. If there is no good reason to port an application to 64 bit (other than the OS developers forcing it), why do it? Windows supported 16bit up until windows 10,and there were absolutely no mainstream desktop applications or even games on 16bit for over a decade at that time. That seems like a good standard. The move to 64bit on the other hand is not all upside. There is overhead for pointer-heavy data structures, which has kept some applications from preferring it for a long time, mainly in the gaming arena. I also remember that browsers were very reticent in moving to 64 bit, until the security benefits from ASLR were overwhelming (and web apps started being so memory hungry that 2-4GB started looking small). Also, the clear technical deficiency that you cite with ObjectiveC on 32 bits (the breaking ABI from adding private fields) is an oft defended feature in the most used native programming language in the world, C++. There, it is done because of performance optimization reasons - to avoid indirection for each structure allocated on the stack. Overall, my point is that the technical case for 64 bit is not nearly as clear-cut as you make it out to be for many applications. I do agree that the ecosystem case for moving to 64 bit is pretty strong, but I don't think it is enough to say that developers who don't do it are idiots and dragging everyone back. And just to be clear, I'm not being defensive or bitter, the applications I work on moved to 64 bit as soon as we could, probably 7 years ago, with very good technical reasons to do so - they were very memory hungry and benefitted greatly from having access to more than 2 GB RAM (Windows).

NobodyNada 7y ago

AFAIK OpenGL hasn't been removed, and isn't planned to be in the near future; it's just been deprecated. Apple isn't adopting new versions of OpenGL or Vulkan, but OpenGL code that used to run on macOS still runs on macOS.

gdxhyrd 7y ago
OpenGL support has been abandoned by Apple years ago, not to mention being broken. The fact that it is now officially deprecated is just a warning from Apple to remove it soon without bad PR.
- xenadu02 7y ago
  You are moving the goalposts. You stated: > What I am upset about is the removal of a standard that worked well That is not correct on either count: 1) OpenGL is a terrible fit for modern GPUs so I don't agree that it "worked well" 2) OpenGL was not removed anyway > OpenGL support has been abandoned That is not correct. Code continues to be written and maintained to keep OpenGL working on newer GPUs, both OpenGL ES on iOS GPUs, as well as OpenGL on mac GPUs. > The fact that it is now officially deprecated is just a warning from Apple to remove it soon without bad PR. macOS/iOS continue to support /many/ deprecated APIs, some of which have been deprecated for over a decade. Contrary to popular opinion, things are not removed just for fun. Things are removed when there is a sound security/technical reason, or when there is a high ongoing cost either to end users or the development process. The alternative is to be MS and never remove anything, and where any changes to observable behavior of the system (or even moving internal struct values around!) can cause breakage and so is not done or requires inserting hacks to preserve behavior. If you think that doesn't impact individual engineer's decision making process ... well I don't know what to tell you. It must be soul-crushing to know if you change an internal data structure from uint16_t to uint32_t some crappy app that depends on being able to poke around will break. Surely such policies encourage some developers to do even more such hacky things, knowing MS will take the blame and end up making sure you can keep getting away with it.
  - saagarjha 7y ago
    > Code continues to be written and maintained to keep OpenGL working on newer GPUs, both OpenGL ES on iOS GPUs, as well as OpenGL on mac GPUs. Yes, but from the outside this is not necessarily obvious. Just ask the VLC developers: they’re running into breakage constantly on macOS. There were a couple of builds back in the summer where OpenGL just wouldn’t initialize at all, meaning even system components like WebGL, iTunes visualizers, and certain screensavers wouldn’t work correctly (though I did notice that there’s a new one written in Metal that wasn’t affected…)
  - pjmlp 7y ago
    > The alternative is to be MS and never remove anything, They do remove stuff, all the time, the transitions just happen to be a bit more gentle, with more years to prepare for it, although not always, e.g. 16 bit, MS-DOS support, WinG, WinRT (Win 8.x variant), WDDM, WCF, Remoting.
  - gdxhyrd 7y ago
    > You are moving the goalposts. No, I am not moving goalposts. OpenGL has been useless for all intents and purposes in macOS for years already. The deprecation is the least of concerns. > 1) OpenGL is a terrible fit for modern GPUs so I don't agree that it "worked well" A terrible fit? What are you even talking about? It is as featureful as the latest D3D11 which is the API most games are based on. What is useless is the OpenGL version and drivers that Apple ships. Please don't spread FUD. There are no security nor technical reason nor significant cost on maintaining a proper OpenGL.

eschaton 7y ago

OpenGL has not been removed from macOS though. It’s just been deprecated.

gdxhyrd 7y ago
See the sibling reply.

xenadu02 7y ago

> Even worse, removal of 32-bit support in macOS 32-bit macOS used a fragile ABI for Objective-C, meaning all ivars had to be in public headers and changing any of them changed the runtime layout of your class and _all_ subclasses. AKA adding a field was a breaking change. This imposed a huge maintenance burden up and down the stack. Often classes would include a void* pointer to a side-table where new fields could be added, or the public class was a wrapper around an internal implementation. Both of those have a performance cost (extra pointer chasing + extra mallocs, or double objc_msgSends for every method/property). There are many other performance optimizations (eg non-pointer ISA) that were impossible on 32-bit, meaning every app that refuses to move to 32-bit imposes even more performance costs. Shipping 32-bit versions of frameworks also bloats the size of the OS and forces the OS to load a duplicate dyld shared cache. It even makes system updates and installs take twice as long (two shared caches need rebuilding after all!) None of this accounts for future optimizations and improvements that would have been nearly impossible if the system still had to support 32-bit without forking half of the userspace frameworks... that kind of forking would be an absolute maintenance nightmare. The deprecation of 32-bit has been obvious for over a decade. It is based on sound technical reasons. You may not agree with those reasons but they have nothing to do with not caring. You might instead ask why a developer would choose to ship a 32-bit app/game anytime after 2010 when 64-bit was available and obviously the future? Should all Mac users continue to pay the cost in disk space, memory, and performance? How long should they pay that cost? Were you hoping macOS would support 32-bit applications in 2030? 2040? What about the undeveloped features and unfixed bugs due to the overhead of continuing to support 32-bit?

tsimionescu 7y ago
In an ideal world, 32bit would continue to be supported for as long as people use 32bit applications. If there is no good reason to port an application to 64 bit (other than the OS developers forcing it), why do it? Windows supported 16bit up until windows 10,and there were absolutely no mainstream desktop applications or even games on 16bit for over a decade at that time. That seems like a good standard. The move to 64bit on the other hand is not all upside. There is overhead for pointer-heavy data structures, which has kept some applications from preferring it for a long time, mainly in the gaming arena. I also remember that browsers were very reticent in moving to 64 bit, until the security benefits from ASLR were overwhelming (and web apps started being so memory hungry that 2-4GB started looking small). Also, the clear technical deficiency that you cite with ObjectiveC on 32 bits (the breaking ABI from adding private fields) is an oft defended feature in the most used native programming language in the world, C++. There, it is done because of performance optimization reasons - to avoid indirection for each structure allocated on the stack. Overall, my point is that the technical case for 64 bit is not nearly as clear-cut as you make it out to be for many applications. I do agree that the ecosystem case for moving to 64 bit is pretty strong, but I don't think it is enough to say that developers who don't do it are idiots and dragging everyone back. And just to be clear, I'm not being defensive or bitter, the applications I work on moved to 64 bit as soon as we could, probably 7 years ago, with very good technical reasons to do so - they were very memory hungry and benefitted greatly from having access to more than 2 GB RAM (Windows).