4 ms·

IOS6 html hardware acceleration changes and how to fix them

38 points by olsn 14y ago

TazeTSchnitzel 14y ago
Having to hint hardware acceleration is bad. The browser shouldn't need to be told. :/
- muellerwolfram 14y ago
  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?
- olsn 14y ago
  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 14y ago
    >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 14y ago
      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 14y ago
        I'm mainly wondering why developers need to hint hardware acceleration. Surely Safari can figure out when it is needed.
        mddw 14y ago
        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.
        TazeTSchnitzel 14y ago
        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.
        rsanders 14y ago
        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.
        Someone 14y ago
        http://developer.apple.com/library/ios/#releasenotes/General/RN-iOSSDK-6_0/_index.html#//apple_ref/doc/uid/TP40012166-CH1-SW19 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/* 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?
endianswap 14y ago
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 14y ago
  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.
  - jarvuschris 14y ago
    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?
    - capisce 14y ago
      I guess that also depends on how efficiently the GPU is used.
  - chadaustin 14y ago
    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 14y ago
      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!
LinaLauneBaer 14y ago
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 14y ago
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 14y ago
  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.
- deleted 14y ago
  [deleted]
pjmlp 14y ago
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 14y ago
  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 14y ago
    hybrid apps are not native.
    - lukifer 14y ago
      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 14y ago
        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 14y ago
        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.

38 points by olsn 14y ago

TazeTSchnitzel 14y ago

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

muellerwolfram 14y ago
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?
olsn 14y ago
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 14y ago
  >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 14y ago
    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 14y ago
      I'm mainly wondering why developers need to hint hardware acceleration. Surely Safari can figure out when it is needed.
      - mddw 14y ago
        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.
        TazeTSchnitzel 14y ago
        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.
        rsanders 14y ago
        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.
        Someone 14y ago
        http://developer.apple.com/library/ios/#releasenotes/General/RN-iOSSDK-6_0/_index.html#//apple_ref/doc/uid/TP40012166-CH1-SW19 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/* 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?

endianswap 14y ago

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 14y ago
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.
- jarvuschris 14y ago
  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?
  - capisce 14y ago
    I guess that also depends on how efficiently the GPU is used.
- chadaustin 14y ago
  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 14y ago
    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!

LinaLauneBaer 14y ago

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 14y ago

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 14y ago
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.
deleted 14y ago
[deleted]

pjmlp 14y ago

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 14y ago
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 14y ago
  hybrid apps are not native.
  - lukifer 14y ago
    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 14y ago
      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 14y ago
        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.