4 ms·
an established industry-standard graphics API. Supported on every platform of note. Sorry, but this mostly wishful thinking. It is only an "industry standard"
by jchb 8y ago
an established industry-standard graphics API. Supported on every platform of note.
Sorry, but this mostly wishful thinking. It is only an "industry standard" on Linux-based systems and Android. Also Nintendo Switch has support for OpenGL, but it is not the primary graphics API.
On Windows, the OpenGL driver quality story is not very rosy. A good example is WebGL. On Windows, Chrome and Firefox implement WebGL using a compatibility library (ANGLE) that maps calls to the Direct3D API. Also for QT applications it is recommended to use ANGLE on Windows.
Playstation 4 has its own proprietary graphics API, Xbox uses DirectX.
- rleigh 8y agoI disagree. It doesn't matter a whit whether or not it's the "primary" graphics API, but rather that it's supported on a platform or not. Right now, if I use OpenGL, I can target Windows, MacOS, Linux, FreeBSD, mobile devices and others all with a single codebase. It is portable, and does work everywhere in practice. On Windows, if you're using a GPU from e.g. AMD or nVidia, be it the gaming end or the workstation end, you will also be getting a decent OpenGL implementation. If you're using software like Alias, you're not going to skimp on the GPU. Angle only exists for poor GPUs which don't have decent OpenGL Windows drivers; for software at this level, they are an irrelevance. WebGL is a red herring. This isn't anything to do with web browsers, and everything to do with killing support for decades of software development investment by third-party ISVs. WebGL is not competing with that, and won't anytime soon. Apple here is basically saying: we don't care about the serious, high-end side of things, and screw any developers who want to develop that type of software for Mac systems. If they did, they would reimplement the OpenGL API on top of Metal; it's not like they don't have the cash to pay for it. As for proprietary gaming consoles, these are also irrelevant to the concerns here. This isn't really about games, or gaming engines. (Though when Apple finally drops OpenGL, most of the back catalogue of games will cease to function…) It's about the thousands of serious software packages out there which will no longer function on a Mac. The high-end CAD and design market. Engineering. Scientific and medical imaging. Etc. That's Apple's choice. And it's my choice to drop Mac support in consequence. They are making it clear that the Mac is no longer the platform for professional software development through their woeful hardware and their poor MacOS maintenance strategy. The market will respond to that.
- jchb 8y agoCan you give an example of a serious software package software that uses OpenGL and targets multiple platforms? I don't doubt you that such exist, I just don't know what to search for. A quick look at for example high-end CAD that you mentioned, Solidworks uses OpenGL, but has as far as I can seen always been Windows only. Its also only lists FirePro and Quadro as recommended graphics cards which support my impression that only workstation-class GPUs have stable OpenGL support on Windows. Autocad uses DirectX 11 on Windows, OpenGL for the Mac version, so they already use platform specific APIs. Software with several decades old code bases, that started out with OpenGL, and perhaps even still uses some of it intermediate mode APIs or display lists, obviously have to continue to rely on it. But if you design a new piece of software today, wouldn't you want it to be able to use the graphics hardware to its full potential and use Vulcan/Metal/DirectX 12?
- rleigh 8y agoMy specialism is scientific imaging, so here's a few examples off the top of my head: VTK would be one. It's at the core of dozens of scientific and medical imaging applications, and is being used for new specialised applications all the time. This does sophisticated volume rendering of 3D images. Used by both open source applications and proprietary. Or OpenSceneGraph, again the core of many applications, also 100% OpenGL. Or Volocity, a commercial OpenGL volume renderer which originated on the Mac, later ported to Windows, which is all OpenGL under the hood. There are hundreds of bespoke scientific and medical applications out there doing analysis and rendering of images. OpenGL is the fundamental underpinning of most of them. Scientists have been using OpenGL for decades. (The availability of OpenGL on the Mac was why many were able to switch.) Some vendors might use DirectX when Windows only, but these are a rarity outside commercial acquisition software due to the ubiquity of Linux and Macs in this domain. This is just the domain I know most about; there are undoubtedly many more in different domains. The workstation class GPUs have some features the gaming ones don't, but it's often equivalent hardware with different drivers, or has some extended capabilities. Double-precision floats, etc. If you don't use these extra features, there's not much practical difference. The actual OpenGL implementations are generally stable for all cases in my experience. The main problem is vendor implementation differences in my experience, e.g. nVidia being laxer than AMD/ATI and allowing broken code to work which others would reject. For new code, I'd like to say Vulkan, but the support isn't fully there yet. For example, Qt 5.12 has Vulkan support but it's not yet universally available, and it's disabled by default unless you compile a custom build from source. I'm currently just starting to get to grips with it for a new project, but it will be hard to deploy for the next year or so. The drivers are there for Windows and Linux, and with the MoltenVk on MacOS X it might well work well enough (I'm yet to progress far enough test this). Unless you are wanting to write multiple rendering backends, Metal and DirectX don't look too great for portable code. I'm hoping Vulkan will be the OpenGL replacement it's touted to be, but we'll see!