Indeed, Apple's Mac OS X QuartzGL framework (GPU accelerated drawing/rasterisation) is slower than the equivalent CPU-based Quartz framework in may cases.
You're being shafted by downvoters who don't really know what they're talking about.
HN user
Indeed, Apple's Mac OS X QuartzGL framework (GPU accelerated drawing/rasterisation) is slower than the equivalent CPU-based Quartz framework in may cases.
You're being shafted by downvoters who don't really know what they're talking about.
Turning on hardware acceleration doesn't cause all Android views to be FBO-backed. You still need to toggle the layerType to LAYER_TYPE_HARDWARE on each view, as far as I'm aware. I think the G+ post is a little disingenuous in that regard.
Google suggests toggling between LAYER_TYPE_NONE & LAYER_TYPE_HARDWARE pre/post animations. This need to actively manage view cache behaviour probably leads to developers being unaware of what to do.
If you're only interested in the canvas-based ASM/C++ walkthrough, you'll find it here:
This is why the graphics APIs are C.
Also, if you're calling an Objective-C method and dynamic dispatch is causing measurable performance issues, you can cache a pointer to the C function that backs the method (called the IMP) via the class_getMethodImplementation() runtime API.
The security at WWDC are Apple employees, according to the one I asked at WWDC08.
TN2239 is invaluable for debugging and digging through things you shouldn't necessarily be poking around in :-)
For that you'd probably want to dig into WebKit.framework — the private WebPluginController & WebPluginDatabase classes look rather interesting.
Hi Ryan,
That's pretty neat! An unfortunate side effect is that running Mobile Safari unsigned negates the 'dynamic-codesigning' entitlement, which means that Nitro is disabled.
That said, a WebGL-enabled UIWebView running in your own app will also not be Nitro-enabled. I've run the PhiloGL spinning world demo on my device and it's running at 40fps, so simpler demos may be possible without a Nitro to boost things a bit.
Cheers,
Nathan
The argument that WebGL "competes" with OpenGL-ES, to the detriment of Apple, makes very little sense to me.
You only need to look at the number of engineers Apple has contributing to WebKit & new web standards (CSS transitions & animations, WebGL etc.).