8 ms·

WebGL on iOS8 Safari and WebView

107 points by glasshead969 12y ago

glasshead969 12y ago
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/ https://developer.apple.com/videos/wwdc/2014/
- lcnmrn 12y ago
  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.
  - glasshead969 12y ago
    Yes, I was trying to convey that webviews are no longer second class.
    - lcnmrn 12y ago
      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/
      - girvo 12y ago
        Woah! Cool project, I usually end up trying to hack something together using Fluid.app to achieve this. Well done :)
        lcnmrn 12y ago
        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.
- elpool2 12y ago
  That's very good news. Now I just want a way to turn off the 300ms tap delay without needing fastclick.
  - lolo_ 12y ago
    Apparently that's fixed in iOS8 :) https://github.com/ftlabs/fastclick/issues/262 https://github.com/ftlabs/fastclick/issues/262
    - kristofferR 12y ago
      "False alarm. iOS 8 simulator: fast clicks. iOS 7 simulator: slow clicks. iOS 8 device: slow clicks."
      - lolo_ 12y ago
        Ack. That is seriously disappointing.
- bdash 12y ago
  To be pedantic, WKWebView from the new, modern WebKit API, gets access to the JIT. The existing UIWebView does not.
- erichate 12y ago
  this is great news, thanks for linking the talk!
wildpeaks 12y ago
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.
double051 12y ago
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'.
imacomputer2 12y ago
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.
- druidsbane 12y ago
  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.
  - imacomputer2 12y ago
    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.
    - druidsbane 12y ago
      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!
    - 0x0 12y ago
      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.
      - imacomputer2 12y ago
        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.
tvon 12y ago
(the site is currently unavailable) Has there been confirmation at WWDC that this will remain enabled through the final release of iOS8?
- ashearer 12y ago
  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.
  - Angostura 12y ago
    I would be surprised if desktop and mobile Safari didn't have comparable rendering capabilities.
- smackfu 12y ago
  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.)
iheart2code 12y ago
Since the site appears to be down, here is a cached version: http://webcache.googleusercontent.com/search?q=cache:wkB31vCCvH0J:blog.ludei.com/webgl-ios-8-safari-webview/+&cd=1&hl=en&ct=clnk&gl=us http://webcache.googleusercontent.com/search?q=cache:wkB31vC... Unfortunately, the images do not appear to be cached.
mrmoka 12y ago
502 nginx error.. looks like their blog didn't handled traffic pressure ;)
- judax 12y ago
  It is back up.
tieTYT 12y ago
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-limitations-on-ios-is-it-possible-to-play-background-music-and http://stackoverflow.com/questions/19365175/with-html5-audio... and http://stackoverflow.com/questions/19365931/does-phonegap-cordovas-media-class-overcome-the-limitations-of-ios-android-audi http://stackoverflow.com/questions/19365931/does-phonegap-co...
- Jare 12y ago
  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.
- AshleysBrain 12y ago
  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?
  - tieTYT 12y ago
    No, i assumed that these problems also applied to the Web Audio API. Thanks for the info
  - azakai 12y ago
    Web Audio also works in Firefox, and IE has pledged to implement it, so things are looking good, even if they aren't quite there yet.
doczoidberg 12y ago
That is good news! Finally I can say to my customers that my products work on all significant platforms.
deleted 12y ago
[deleted]
yoran 12y ago
Can someone tell me what the recent negative news around OpenGL (see for instance http://www.alexstjohn.com/WP/2014/06/03/apple-ditching-opengl/ 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.
- mortenjorck 12y ago
  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.
- _random_ 12y ago
  Mixing a legacy platform with a legacy language just isn't working out.
  - Touche 12y ago
    I'm not sure what you mean here... what isn't work?
- mikeash 12y ago
  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.
  - pjmlp 12y ago
    Technically you don't need OpenGL for WebGL, it just makes the implementation easier.
- mantrax5 12y ago
  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.
0x0 12y ago
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.
- xcntktn 12y ago
  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.
  - 0x0 12y ago
    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 https://news.ycombinator.com/item?id=7783137
  - madeofpalk 12y ago
    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.
    - 0x0 12y ago
      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.
AKluge 12y ago
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.
sunsu 12y ago
Now if only we could get some WebRTC support! Has anyone heard anything about that in iOS8?
- Continuous 12y ago
  Unfortunately no, No WebRTC audio/video or data!
DonHopkins 12y ago
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"] ... https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Webkit/Classes/WebScriptObject_Class/Reference/Reference.html https://developer.apple.com/library/mac/documentation/Cocoa/... http://blog.impathic.com/post/64171814244/true-javascript-uiwebview-integration-in-ios7 http://blog.impathic.com/post/64171814244/true-javascript-ui... http://asciiwwdc.com/2013/sessions/615 http://asciiwwdc.com/2013/sessions/615 http://www.steamclock.com/blog/2013/05/apple-objective-c-javascript-bridge/ http://www.steamclock.com/blog/2013/05/apple-objective-c-jav... http://stackoverflow.com/questions/2254372/calling-javascript-from-objective-c-via-webscriptobject http://stackoverflow.com/questions/2254372/calling-javascrip... http://will.thimbleby.net/script/ 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

107 points by glasshead969 12y ago

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/ https://developer.apple.com/videos/wwdc/2014/

lcnmrn 12y ago
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.
- glasshead969 12y ago
  Yes, I was trying to convey that webviews are no longer second class.
  - lcnmrn 12y ago
    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/
    - girvo 12y ago
      Woah! Cool project, I usually end up trying to hack something together using Fluid.app to achieve this. Well done :)
      - lcnmrn 12y ago
        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.
elpool2 12y ago
That's very good news. Now I just want a way to turn off the 300ms tap delay without needing fastclick.
- lolo_ 12y ago
  Apparently that's fixed in iOS8 :) https://github.com/ftlabs/fastclick/issues/262 https://github.com/ftlabs/fastclick/issues/262
  - kristofferR 12y ago
    "False alarm. iOS 8 simulator: fast clicks. iOS 7 simulator: slow clicks. iOS 8 device: slow clicks."
    - lolo_ 12y ago
      Ack. That is seriously disappointing.
bdash 12y ago
To be pedantic, WKWebView from the new, modern WebKit API, gets access to the JIT. The existing UIWebView does not.
erichate 12y ago
this is great news, thanks for linking the talk!

wildpeaks 12y ago

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.

double051 12y ago

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'.

imacomputer2 12y ago

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.

druidsbane 12y ago
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.
- imacomputer2 12y ago
  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.
  - druidsbane 12y ago
    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!
  - 0x0 12y ago
    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.
    - imacomputer2 12y ago
      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.

tvon 12y ago

(the site is currently unavailable) Has there been confirmation at WWDC that this will remain enabled through the final release of iOS8?

ashearer 12y ago
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.
- Angostura 12y ago
  I would be surprised if desktop and mobile Safari didn't have comparable rendering capabilities.
smackfu 12y ago
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.)

iheart2code 12y ago

Since the site appears to be down, here is a cached version: http://webcache.googleusercontent.com/search?q=cache:wkB31vCCvH0J:blog.ludei.com/webgl-ios-8-safari-webview/+&cd=1&hl=en&ct=clnk&gl=us http://webcache.googleusercontent.com/search?q=cache:wkB31vC... Unfortunately, the images do not appear to be cached.

mrmoka 12y ago

502 nginx error.. looks like their blog didn't handled traffic pressure ;)

judax 12y ago
It is back up.

tieTYT 12y ago

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-limitations-on-ios-is-it-possible-to-play-background-music-and http://stackoverflow.com/questions/19365175/with-html5-audio... and http://stackoverflow.com/questions/19365931/does-phonegap-cordovas-media-class-overcome-the-limitations-of-ios-android-audi http://stackoverflow.com/questions/19365931/does-phonegap-co...

Jare 12y ago
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.
AshleysBrain 12y ago
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?
- tieTYT 12y ago
  No, i assumed that these problems also applied to the Web Audio API. Thanks for the info
- azakai 12y ago
  Web Audio also works in Firefox, and IE has pledged to implement it, so things are looking good, even if they aren't quite there yet.

doczoidberg 12y ago

That is good news! Finally I can say to my customers that my products work on all significant platforms.

deleted 12y ago

[deleted]

yoran 12y ago

Can someone tell me what the recent negative news around OpenGL (see for instance http://www.alexstjohn.com/WP/2014/06/03/apple-ditching-opengl/ 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.

mortenjorck 12y ago
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.
_random_ 12y ago
Mixing a legacy platform with a legacy language just isn't working out.
- Touche 12y ago
  I'm not sure what you mean here... what isn't work?
mikeash 12y ago
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.
- pjmlp 12y ago
  Technically you don't need OpenGL for WebGL, it just makes the implementation easier.
mantrax5 12y ago
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.

0x0 12y ago

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.

xcntktn 12y ago
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.
- 0x0 12y ago
  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 https://news.ycombinator.com/item?id=7783137
- madeofpalk 12y ago
  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.
  - 0x0 12y ago
    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.

AKluge 12y ago

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.

sunsu 12y ago

Now if only we could get some WebRTC support! Has anyone heard anything about that in iOS8?

Continuous 12y ago
Unfortunately no, No WebRTC audio/video or data!

DonHopkins 12y ago

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"] ... https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Webkit/Classes/WebScriptObject_Class/Reference/Reference.html https://developer.apple.com/library/mac/documentation/Cocoa/... http://blog.impathic.com/post/64171814244/true-javascript-uiwebview-integration-in-ios7 http://blog.impathic.com/post/64171814244/true-javascript-ui... http://asciiwwdc.com/2013/sessions/615 http://asciiwwdc.com/2013/sessions/615 http://www.steamclock.com/blog/2013/05/apple-objective-c-javascript-bridge/ http://www.steamclock.com/blog/2013/05/apple-objective-c-jav... http://stackoverflow.com/questions/2254372/calling-javascript-from-objective-c-via-webscriptobject http://stackoverflow.com/questions/2254372/calling-javascrip... http://will.thimbleby.net/script/ 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