WebGL on iOS8 Safari and WebView(blog.ludei.com)
blog.ludei.com
WebGL on iOS8 Safari and WebView
http://blog.ludei.com/webgl-ios-8-safari-webview/
15 comments
Now if only we could get some WebRTC support! Has anyone heard anything about that in iOS8?
Unfortunately no,
No WebRTC audio/video or data!
No WebRTC audio/video or data!
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.
More info in this talk: Introduction to Modern Webkit Api https://developer.apple.com/videos/wwdc/2014/
More info in this talk: Introduction to Modern Webkit Api https://developer.apple.com/videos/wwdc/2014/
To be pedantic, WKWebView from the new, modern WebKit API, gets access to the JIT. The existing UIWebView does not.
That's very good news. Now I just want a way to turn off the 300ms tap delay without needing fastclick.
Apparently that's fixed in iOS8 :)
https://github.com/ftlabs/fastclick/issues/262
https://github.com/ftlabs/fastclick/issues/262
"False alarm. iOS 8 simulator: fast clicks. iOS 7 simulator: slow clicks. iOS 8 device: slow clicks."
Ack. That is seriously disappointing.
Actually is the other way around, Safari on both OS X and iOS is built on top of the WebView which is part of WebKit framework.
Yes, I was trying to convey that webviews are no longer second class.
Yes, they are not anymore. I built a browser recently, everything works as fast as Safari, yet in some cases due to smaller viewport it works faster.
http://lucianmarin.com/monochrome/
http://lucianmarin.com/monochrome/
this is great news, thanks for linking the talk!
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.
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'.
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'.
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.
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!
(the site is currently unavailable)
Has there been confirmation at WWDC that this will remain enabled through the final release of iOS8?
Has there been confirmation at WWDC that this will remain enabled through the final release of iOS8?
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.
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.
I would be surprised if desktop and mobile Safari didn't have comparable rendering capabilities.
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.)
Since the site appears to be down, here is a cached version: http://webcache.googleusercontent.com/search?q=cache:wkB31vC...
Unfortunately, the images do not appear to be cached.
Unfortunately, the images do not appear to be cached.
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?
Here's the details of my complaint: http://stackoverflow.com/questions/19365175/with-html5-audio... and http://stackoverflow.com/questions/19365931/does-phonegap-co...
Here's the details of my complaint: http://stackoverflow.com/questions/19365175/with-html5-audio... and http://stackoverflow.com/questions/19365931/does-phonegap-co...
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.
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?
That is good news! Finally I can say to my customers that my products work on all significant platforms.
[deleted]
Can someone tell me what the recent negative news around OpenGL (see for instance http://www.alexstjohn.com/WP/2014/06/03/apple-ditching-openg...) means for the future of WebGL? I don't follow the graphics world from close, therefore my question.
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.
It's just becoming a more interesting trade-off with OpenGL.
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.
Technically you don't need OpenGL for WebGL, it just makes the implementation easier.
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.
That's really it. No conspiracy theories.
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.
That's really it. No conspiracy theories.
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.
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.
I'm honestly not sure what to make of it.
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.
Btw, I did pretty much call this one out two weeks ago: https://news.ycombinator.com/item?id=7783137
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.
Btw, I did pretty much call this one out two weeks ago: https://news.ycombinator.com/item?id=7783137
Well, the statement was kind of wrong.
Metal isnt really an OpenGL replacement. Most people would use it in their apps - you don't write games in metal, you write game engines in it.
Metal isnt really an OpenGL replacement. Most people would use it in their apps - you don't write games in metal, you write game engines in it.
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.
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.
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"] ...
https://developer.apple.com/library/mac/documentation/Cocoa/...
http://blog.impathic.com/post/64171814244/true-javascript-ui...
http://asciiwwdc.com/2013/sessions/615
http://www.steamclock.com/blog/2013/05/apple-objective-c-jav...
http://stackoverflow.com/questions/2254372/calling-javascrip...
http://will.thimbleby.net/script/
Here is the header file, the best documentation available:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk/System/Library/Frameworks/JavaScriptCore.framework/Headers/JSContext.h