Can someone please explain what tradeoff is being made when Apple decides to hardware accelerate something in their browser? Is it that hardware accelerated elements are more fluid/responsive but require more battery consumption to perform?

I'm used to the PC world where battery/heat are hardly a problem and software rendering is usually a bad thing when hardware rendering is available.

In this case, "hardware accelerated" means drawing web content into an offscreen image -- as the content is transformed using CSS, the image is re-drawn and blended using the GPU. This is faster than re-laying-out and re-drawing the web content directly (even if re-drawing the web content itself uses the GPU). It's a good trade-off when you have animations that update every frame.

The biggest cost is memory. Every pixel of hardware accelerated web content gets 4 bytes of memory. This adds up quickly, especially since any content that overlaps hardware accelerated content must become hardware accelerated as well.

The other big cost, as olsn already pointed out, is that blending these offscreen images onto the screen takes time and power on every frame. In extreme cases this can cause scrolling to stutter.

See the "Optimizing Web Content in UIWebViews and Websites on iOS" session from WWDC 2012 for more information about this.

Yes, battery is consumed faster when using the GPU - I cannot tell you by how much, but obviously it is enough on iOS devices for Apple to change its feature sets there.

Can you give a citation or backing research? In my experience, if you've got two similar operations, the one on the GPU will consume less power (assuming you don't need to transfer substantially more data over the bus).

i'm not an hardware expert, so I cannot tell you excactly how it works, but the point is: The device will calculate the same result in shorter time -> from what I know: If you want to calculate faster, you need more energy Also I don't think the devices are built to supply the CPU with less power while using the GPU.

Again: these are mostly assumptions, I'm not a hardware architect!

But for doing graphic manipulations, wouldn't it make sense that the net energy used by the GPU getting them done should be less than with the CPU?

I guess that also depends on how efficiently the GPU is used.

Having to hint hardware acceleration is bad. The browser shouldn't need to be told. :/

Not all sites/apps need hardware acceleration and those who do consume a lot more battery. So there is kind of a reason for this - however the way apple implemented this is not from the best quality I think.

The bottom line is, that Apple forces developers to take care of this instead of having everything automatically hardware accalerated and therefore shortening the battery life of iOS devices(by a lot I'm guessing).

>and therefore shortening the battery life of iOS devices

Does rendering a few more polygons actually kill battery life that badly? I believe much of the OS is already hardware accelerated anyway.

GPU usage does cost battery life, I cannot say how much - but on the other hand I cannot think of any other reason why they wouldn't use hardware acceleration on websites automatically (or allway)

I'm mainly wondering why developers need to hint hardware acceleration. Surely Safari can figure out when it is needed.

What I can't figure is why 2D transitions needs to be hardware accelerated to be smooth in mobile Safari.

Neither why their mighty Nitro JavaScript Engine can't handle smoothly a setTimeOut based fade in/Out.

Google Chrome on 8 years old hardware (less powerful than actual iPhone hardware) renders the moving web better.

Safari is a poor mobile browser.

http://developer.apple.com/library/ios/#releasenotes/General... (referenced from the article) states

"WebKit on iOS now supports the requestAnimationFrame and cancelAnimationFrame methods in JavaScript, as described here: http://www.w3.org/TR/animation-timing/*

That link in turns states:

"script-based animations are most often performed by scheduling a callback using setTimeout or setInterval and making changes to the DOM to effect the animation in that callback.

A disadvantage of this approach is that the author of the animation script has no idea what the ideal frequency for updating their animation is. Instead, the easiest way forward for the author is to simply call setTimeout with a very small value, which in practice will be clamped to some minimum time like 10ms anyway. It likely won’t be the case that 100 updates per second are required for the animation, especially if the page is in a background tab or the browser window is minimized."*

So, it looks like setTimeOut is discouraged in favour of this (draft) standard. Given that, I would understand that Apple would optimize setTimeOut for minimal power use, rather than maximum update frequency (not that I have the faintest idea about how one should go about that)

Also: have you tried your claim about Chrome's performance in a similar amount of memory as what iOS has to deal with?

What's a better one, and how is it better? Mobile Safari's pretty widely acknowledged to implement a much better HTML5 experience, for example, and clearly it can be made to make good use of hardware acceleration for modern non-document-ish uses of CSS.

I think it's because Safari likes to cache the page as an image and avoid re-rendering it where possible. This is an assumption of mine, but I suspect it is the reason why position: fixed used to be broken on Mobile Safari.

agreed. in the release note it says "Authors should stop using this option as a way to get hardware acceleration"... this sounds like there is an other option to do it, does anyone know?

If they disabled the hardware acceleration because the GPU requires more battery I wonder if they have factored in that the rendering needs more time to complete => users will have to stay on the website longer => they have to keep their screen turned on longer which costs also a lot of power...

The conspiracy-minded might suspect that the real reason for this might have been to keep web view based apps inconvenient to develop, and poorly performing, to nudge developers towards native ObjC-based apps. Which are coincidentally harder to port to other platforms.

It would, however, indeed be paranoid and crazy.

The WebKit developers spend all day trying to drive the web forward. That's what they do. They're not pulling their punches. Try hanging out in #webkit on irc for a bit and see if you think they want the web to lose to native.

Here's how you make a tasty burger: make a tasty chicken sandwich instead. :P

The issue affects websites as well as hybrid apps. Given that this change is poorly documented by Apple, and it directly affects a JS plugin I'm working on, I'm quite grateful for the OP sharing their findings.

hybrid apps are not native.

I know that. But your comment was like answering a question about optimizing a Python snippet with a recommendation to use C++. If you don't like hybrid apps (or Python, or whatever), that's fine, but it doesn't mean that bringing it up aids the discussion. Trust the developer to understand the tradeoffs of their tools and stack.

My point is that native applications are the only way to take proper advantage of the hardware.

You cannot try to bend something thought to display documents into some kind of application, and they complain about lack of hardware acceleration.

Why not have a document with hardware accelerated effects? Anyway, we're talking about a feature which already existed and worked quite well, which Apple felt the need to discourage the use of, probably for battery reasons. Which is fine, but it's annoying that they didn't document it in more detail.

It's ultimately the developer's responsibility to make good choices on behalf of users, whether on native, hybrid, or the mobile web.