

IOS6 html hardware acceleration changes and how to fix them - olsn
http://indiegamr.com/ios6-html-hardware-acceleration-changes-and-how-to-fix-them/

======
endianswap
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.

~~~
olsn
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.

~~~
chadaustin
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).

~~~
olsn
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!

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

~~~
olsn
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).

~~~
TazeTSchnitzel
>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.

~~~
olsn
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)

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

~~~
mddw
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.

~~~
Someone
[http://developer.apple.com/library/ios/#releasenotes/General...](http://developer.apple.com/library/ios/#releasenotes/General/RN-
iOSSDK-6_0/_index.html#//apple_ref/doc/uid/TP40012166-CH1-SW19) (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?

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

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

~~~
kenferry
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.

------
pjmlp
Easy solution, just implement the application in native code.

No need for workarounds and hints in an application whose main function is to
display _documents_.

~~~
lukifer
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.

~~~
pjmlp
hybrid apps are not native.

~~~
lukifer
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.

~~~
pjmlp
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.

~~~
lukifer
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.

