It also looks like both iOS and OSX are using same Webkit Api. Webviews get the same stuff Safari has access to, which mean Webviews also get access to JIT compilation including FTL tier.
Thank you! If there are cool mobile pages missing from Monochrome start page, please make a submission. The app is native and much faster than running Fluid.
This is very exciting for a number of reasons. Apple's platforms were some of the first to adopt WebGL (you could turn on WebGL in any iOS WebView with private APIs three years ago), but they were the last to turn it on by default.
Hell, even Microsoft beat them to the punch with IE11, but at least the implementation in Safari is 'complete' and 'comprehensive', as opposed to the silly restrictions in IE like 'floating point vertex attributes only'.
It's quite the funny coincidence that WebGL is being made available to HTML5 apps at the same time that the native SDK gets an OpenGL replacement in Metal with "up to 10x performance". Yet again it would appear that HTML5/webapp remains a second class citizen to the native app experience.
I don't know why you're being downvoted for that; your interpretation, while uncharitable, is still most likely the correct one, given Apple's history.
Not to mention the games market for the iOS App Store is very saturated and most of the money has likely been sucked out of it for the time being, so now Apple finds they don't have much to lose by allowing the possibility of OpenGL-based games for iOS which bypass the App Store.
In case anyone is quick doubt or dismiss the above criticism, just recall that for years Apple's iAd framework officially supported WebGL, but Safari and UIWebView did not. This implies that Apple could have released WebGL support in Safari and/or UIWebView any time they wanted; they simply chose not to for for non-technical (i.e., business) reasons.
Although I disagree that it was purely non-technical limitations. Quite possibly they didn't want to enable webgl in the wild until they had the out-of-process, super sandboxed webview implementation.
The end result is the same though? If you want to publish a game through the web, your game (or your game engine) has to target webgl. If you go native, your game (or your game engine) can target metal instead and gain a massive performance advantage.
No, you don't target metal - you use the Unreal engine which is now using metal underneath in an implementation detail that most developers wont worry about.
I'm a hobbyist game dev, and although I appreciate this, I'm disappointed that sound works so poorly on mobile in html5 and I actually consider that a bigger issue than this (after all, my game already renders fine in the 2d canvas). Why don't others seem to care about this issue? Is it because they plan to use WebGL for something that doesn't need sound or is it because they know of some sound workaround that I've never heard of?
In general, you are right to complain, audio in the web is always a problem; the only debate is about just how much and in how many ways it is broken.
In practice, you probably want to take a look at Howler.js - it's pretty comprehensive library that tries its best to overcome the various limitations and problems.
The Web Audio API - supported in Safari and Chrome for Android - solves this pretty well. You can even connect up HTML5 audio to play through Web Audio for features like streaming long tracks and still be able to process them. Is there something still wrong with that?
Finally a link about WebGL on iOS is upvoted enough to land on the frontpage: I was hoping to see what would be HN's reaction about the news yesterday, but no submission seemed to get through.
Any changes in the lovely JavaScript/Objective-C bridging stuff on iOS8? Does it work with the new stuff WebKit? Is it any better documented or have more features?
MacOS since 10.3 has the handy WebScriptObject / JSContext stuff, which made it into iOS 7, but wasn't very well documented, and took some tricks to use. You have to fish a JSContext out of the WebView with [webView valueForKeyPath: @"documentView.webView.mainFrame.javaScriptContext"] ...
This is great news! I've been disappointed with the slow adoption of webgl in mobile webviews. This will make it easier to create mobile HTML5 apps with animations that look as good as native apps.
Wouldn't that be too taxing on battery life? I'd rather have WebGL used for 3D games or visualizations where I at least know the impact beforehand rather than like flash or as a CSS animation alternative.
That's a good point. I've never compared the battery usage. But you don't have to make everything 3D (I think). I think you can use WebGL in a 2D context and the battery impact is probably less significant.
Mostly, I just want to avoid learning each mobile platform just to make one app. That's been turning me off from mobile development for years. I'd rather use something like Cordova with webgl and hit all mobile platforms in one shot.
I've never heard of "WebGL in a 2D context". WebGL is WebGL is WebGL - it's a WebGL context. Whether or not you decide to feed it drawing commands that will end up looking like a 3d object or like a 2d sprite is up to you.
I was thinking of a 2d canvas context. Basically, I would expect battery consumption to be lower when WebGl is rendering 2d than it would be if it were rendering 3d. It just seems intuitive that 3d requires more computation. But I really don't know. I've never seen any battery usage comparisons.
the browser may be able to optimize the 2D canvas operations by using the GPU more efficiently, but drawing with the webgl stack is going to suck the same amount of battery whether doing 2D or 3D. After all, 3D is really just correctly positioned 2D triangles.
It would be interesting to see what the impact would be in a more limited context as you suggest. Also, having it as part of a toolkit would lessen the burden and allow for continuous optimization. Exciting times!
Given that the same company that's "ditching OpenGL" according to that article is the one now throwing their weight behind WebGL, I think it's safe to say that the article in question is overblown. Apple isn't ditching OpenGL. In fact, OpenGL remains the only 3D acceleration API available on Macs. Apple just added another API with lower overhead to certain devices.
There's a trend afoot toward vertically-integrated graphics pipelines and APIs for driven by the enhanced efficiency and easier optimization they offer. This really only further highlights OpenGL's benefit of portability, though.
It's just becoming a more interesting trade-off with OpenGL.
Those are not negative news, just the speculation of Some Dude on the Internet.
Apple is not abandoning OpenGL, heck, SpriteKit and SceneKit are both laid on top of OpenGL.
The fact is OpenGL doesn't allow the underlying hardware to be fully utilized, so now those demanding best performance can use Metal. A good example would be a high-end gaming engine like Unreal. And those who don't, can keep using OpenGL forever.
All the FUD about walled garden and proprietary APIs ignore how Metal is supposed to be used. Engines like Unreal already support OpenGL, DirectX, the PlayStation variation of OpenGL-ish API, Mantle (AMD) and so on.
Now it'll support also Metal.
People who use the Unreal engine can still write cross-platform games for it, but now they'll get even better performance under iOS thanks to Metal.
This is great news. I, and others, use WebGL to generate realistic interactive educational content. Not falling back to images or SVG on iOS will provide a more effective experience on one of the most popular educational platforms. It's a win for more than games. We can even offload computations from some simulations onto the GPU.
Yes, there was a very brief mention of WebGL as a Safari feature during the keynote.
Edit: On second thought, don't take that as proof. I was thinking of the Mac OS X portion, and I don't recall them calling it out specifically for iOS.
There's a WWDC session on it tomorrow, that would be worth checking out afterwards if you are interested. (Free developers can access WWDC videos and slides.)
More info in this talk: Introduction to Modern Webkit Api https://developer.apple.com/videos/wwdc/2014/