Apple Proposing A New, Lower-Level Graphics API For The Web

[geearf]

I think, you are underestimating development time. While the open drivers for vulkan seem to be progressing quickly now, coming up with a good API takes longer. My guess is that Apple startet their work on Metal long before AMD announced Mantle to the public. The only space that has been using low level APIs for a long time is the XBox/PS sort of thing. My guess is, AMD and Apple saw the need to reduce CPU-Overhead in parallel. AMD learned from their involvement in the development of the current gen consoles and Apple just needed to drive the (at that time) insanely high pixel counts in their mobile devices with a relatively good GPU and a relatively slow mobile CPU. At the time, Mantle was announced, their plans concerning Metal were most likely already pretty far along.

I am not underestimating anything, that's pretty much what I meant in my message.

[oooverclocker]

If they can't support OpenGL 4.5, WebGL 1/2, or Vulkan - they shouldn't be proposing a standard.
They need to start following standards more before the other industry players should trust them.

And you got your 30st like because that's entirely true. When there is need for a successor of WebGL it's WebVulkan and nothing else.

[paulpach]

You mean like WebGL which started out at Mozilla and now is developed by the Khronos WebGL Working Group?

No. WebGL is based on OpenGL, it uses the same old model and it is already well supported by all major browsers. I am talking about a modern API, one that does not have the overhead of OpenGL (the reason Vulkan was invented in the first place).

As of now, nobody is pushing for anything to replace WebGL.. except Apple.

[-MacNuke-]

As of now, nobody is pushing for anything to replace WebGL.. except Apple.

Because nobody wants possible LowLevel memory-management on your GPU from your browser. What Apple is proposing there is just an API that fits to Apples Metal API so they do not have to upgrade their OpenGL implementation... I mean, they only support OpenGL 4.1 or 4.2...

[cj.wijtmans]

webgl is good for the web. Apple is the new microsoft. They should support vulkan or get lost.

[Tomin]

Also, am I really the only one who's concerned about the idea of a low level API for web browsers?

No, you are not. That is what I was thinking when I read the news.

[Marc Driftmeyer]

Metal started in June 2014, Direct3D 12 in July 2015.
Mantle was from February 2014.
Now the question is when was Apple aware of Mantle. I always thought that like D3D it was inspired by it, but the release date are so close...

Metal was publicly released in June 2014. It has been in-house developed for 3 years prior. It takes 3 to 5 years of internal development before any API is released by Apple. Just talking as someone who worked there.

[efikkan]

Another API? We have more than enough APIs already, and web browsers have already added too much functionality the last few years to ever make it bug free.

So Apple is trying to make a "low level" object oriented API for JavaScript, yeah right, they are certainly doing it wrong. There is no way this is going to be efficient.

[linuxgeex]

Another API? We have more than enough APIs already, and web browsers have already added too much functionality the last few years to ever make it bug free.

So Apple is trying to make a "low level" object oriented API for JavaScript, yeah right, they are certainly doing it wrong. There is no way this is going to be efficient.

The feature set and code base of modern browsers is expanding too damn quick for there to be eyes on the code long enough to ensure it is secure.

I hope that in the relatively near future we have 2 things: sandboxing/isolation of all foreign media rendering systems, and, a move by W3C to select a functional subset of existing WWW standards and deprecate the rest so that browsers can become fast, light, minimal, and remain functional and small enough that a handful of developers can actually understand the entire operation of every part of it... so that there's a hope in hell that "with enough eyes, any bug is shallow" can apply. Obviously a browser can only be so light. We need a fast javascript implementation so that's going to entail a 4-level interpreter/JIT/optimising compiler and opcode cache. We need to have assorted media rendering libraries. We need to have a fast layout engine which speaks to a variety of native APIs for good performance. We need cloud sync of credentials and preferences. But there's no reason these all have to be NOT-INVENTED-HERE vertically developed solutions. They can be shared with other native applications, the platform UI, even the OS itself, and that will expand the ratio of eyes to source lines of code. The browser code itself could be drastically reduced, which in turn would mean we could have a larger variety of innovative competing browser products for the same overall development cost.

Oh wait. Google and Mozilla would never go for anything that threatened the Oligopoly which allows for their dominance to continue. Silly me.

[Vistaus]

The feature set and code base of modern browsers is expanding too damn quick for there to be eyes on the code long enough to ensure it is secure.

I hope that in the relatively near future we have 2 things: sandboxing/isolation of all foreign media rendering systems, and, a move by W3C to select a functional subset of existing WWW standards and deprecate the rest so that browsers can become fast, light, minimal, and remain functional and small enough that a handful of developers can actually understand the entire operation of every part of it... so that there's a hope in hell that "with enough eyes, any bug is shallow" can apply. Obviously a browser can only be so light. We need a fast javascript implementation so that's going to entail a 4-level interpreter/JIT/optimising compiler and opcode cache. We need to have assorted media rendering libraries. We need to have a fast layout engine which speaks to a variety of native APIs for good performance. We need cloud sync of credentials and preferences. But there's no reason these all have to be NOT-INVENTED-HERE vertically developed solutions. They can be shared with other native applications, the platform UI, even the OS itself, and that will expand the ratio of eyes to source lines of code. The browser code itself could be drastically reduced, which in turn would mean we could have a larger variety of innovative competing browser products for the same overall development cost.

Oh wait. Google and Mozilla would never go for anything that threatened the Oligopoly which allows for their dominance to continue. Silly me.

I agree about the W3C part, but I sure hope browser vendors will actually follow it. They're not always following the W3C standard as of now, so...