Apple Announces A New 3D API, OpenGL Competitor: Metal

[movieman]

Sad really, Google needs to reboot Android soon or Apples battles of the future will be against Windows again.

I'm sure Google are really worried about their, what, 80%? 90%? marketshare on mobile devices around the world.

Personally, I've considered buying some apps on Android, but, every time I think about it, I realize it requires giving my credit card number to Google, who will just use it as another way to track me. So, I don't.

So I keep going with the free apps, which do pretty much everything I ever want to do on a tablet.

[jimbohale]

Well the idea of moving away from Obj-C is a good one since that's just an awful language to have to deal with. Whether or not Swift is any good I don't have any details to judge yet and I think we'll all need some experience with it to see if it's up to snuff.

I'm not a big fan of platform-specific languages but Apple has always been an insular company, even a bit more than MS I think. There are a variety of existing languages that likely fit the bill fine which could have been selected. In general I'm kind of frustrated by the industry trend to pop a new fad language every six months. Whether that's Go or Rust or whatever, etc.

I have a Mac Dev license for work, and just for the sake of doing it I've used swift for a few days and it's really, really good (I've used practically every major UI toolkit in C, C++, Objective-C, Vala). It needs to be open sourced in Clang and GCC needs to add in support for it. The after that happens Qt needs to add in support for Swift. It would be so very much easier to write half-decent UI apps.

[0xBADCODE]

"Competitor"? Oh, really?

OpenGL is good because it is cross platform. And where is this "metal" API would be implemented? Only some apple stuff? Then it likely to compete DX in some regards but not anyhow comparable to OpenGL.

[przemoli]

OpenGL ES is OpenGL ES.

For given effect you use SAME OpenGL ES commands on different OpenGL ES implementations (given both support that functionality).

Language used is irrelevant, and if such approach do not work, its IMPLEMENTATION bug, not OpenGL ES bug.

So if porting from iOS to Android (and vice versa) is hard, that is because of the code BESIDE OpenGL ES.

Ofc. quality of OpenGL ES implementations is different matter (since Apple stick to only PowerVR their buggy implementation is Consistently Buggy, on Andorid each OpenGL ES vendor have their own bug sets).

Now with Metal, porting from it to OpenGL ES 2.0 (very common) will be harder (as Metal allow for using functionality not present in 2.0). But porting to OpenGL ES 3.0? Not so hard (compute are not there, so special care for using OpenCL would be needed). OpenGL ES 3.1? All functionality present and accounted for!

PS Currently there are more Android devices with OpenGL ES 3.0 present that of any iOS devices. Time will tell how quickly Android 3.1 devices will displace iOS numbers.

[przemoli]

Few thing Google can do to quickly and cheaply improve OpenGL ES chances against Metal:

1) Adding OpenGL ES conformance test to the Android certification process. That would instantly started to improve quality situation of implementations. And Piglit test suite is freely available as starting point.
2) Adding support of OpenGL ES 3.1 to Android ASAP. (Should not take too many months, and even clear message "we are commited" would help)
3) Joining Khronos. (That would be equal to 2, but with stronger message about future)
4) Writing docs for OpenGL ES 3.1 for Android.

[deanjo]

Few thing Google can do to quickly and cheaply improve OpenGL ES chances against Metal:

1) Adding OpenGL ES conformance test to the Android certification process. That would instantly started to improve quality situation of implementations. And Piglit test suite is freely available as starting point.
2) Adding support of OpenGL ES 3.1 to Android ASAP. (Should not take too many months, and even clear message "we are commited" would help)
3) Joining Khronos. (That would be equal to 2, but with stronger message about future)
4) Writing docs for OpenGL ES 3.1 for Android.

As long as Google keeps pushing a VM solution they will always be at a disadvantage. VM's are nice and offer a wide range of compatibiliy but will always take second place to native code.

[przemoli]

As long as Google keeps pushing a VM solution they will always be at a disadvantage. VM's are nice and offer a wide range of compatibiliy but will always take second place to native code.

That is why Google DO allow for native code.

But that is important for code that run on CPU, GPU do not care if commands where issued from VM, C, JIT, or whatever.

OpenGL ES is available from both Dalvik and Native.

[V10lator]

The OpenGL ES implementation on Android and iOS are different. They wind up providing the same functions but in different programming languages.

So it's not OpenGL ES giving you porting issues but the programming language? In other words: Even if you wouldn't use OpenGL ES you would have the exact same porting issues?

Also don't forget that you are able to use the exact same programming languages on both, iOS and Android. This was already pointed out, so don't ignore it:

Except Android is in no way tied to Java. Use the NDK and you can write C and C++ code, and you're already a lot closer (and yes, Android has a C OpenGL ES library).
Hack the NDK a little and you can write Objective-C code (Edit the rebuilt scripts that come with the NDK to use --enable-languages=objc when building gcc, then rebuild. Bundle the libobjc runtime library with your app. And yes, I've actually done this, so I know what I'm talking about) - and suddenly porting iOS code that uses standard APIs like OpenGL ES becomes an easy and quick thing (iOS code that heavily relies on Cocoa Touch is a different matter).

[jimbohale]

Few thing Google can do to quickly and cheaply improve OpenGL ES chances against Metal:

1) Adding OpenGL ES conformance test to the Android certification process. That would instantly started to improve quality situation of implementations. And Piglit test suite is freely available as starting point.
2) Adding support of OpenGL ES 3.1 to Android ASAP. (Should not take too many months, and even clear message "we are commited" would help)
3) Joining Khronos. (That would be equal to 2, but with stronger message about future)
4) Writing docs for OpenGL ES 3.1 for Android.

OpenGL ES on Android already has Metal on iOS beat and they know it. The reason is that non-Apple hardware in high-end phones and tablets tends to be very powerful. So much more so than Apple's offering that I doubt that Metal would outperform it on most instances.

I agree with your points, as well. 100%. It's not that I think that they have to do them for OpenGL ES to succeed because it's going to anyways, I think that Google should do it anyways out of principle.

[scottishduck]

OpenGL ES on Android already has Metal on iOS beat and they know it. The reason is that non-Apple hardware in high-end phones and tablets tends to be very powerful. So much more so than Apple's offering that I doubt that Metal would outperform it on most instances.

...Apple A7 remains the most powerful mobile SoC