I personally love the  ‘-webkit-overflow-scrolling: touch’-feature as it allows you to implement a scroll pane for mobile devices with just writing two lines of css and no need of hasseling around with JS to make some content scroll smooth ect., however this approach also comes with a drawback: hardware acceleration will cause performance-issues on iOS (maybe other mobile devices, though it was only tested on an iPad2 running iOS6)

In my last post I was writing about forcing html5 hardware acceleration on iOS6, turns out you do NOT want to do that on every element as this can also cause the performance to drop, pointed out by the following example:

The scenario is the following: The base is a big scrollpane using ‘-webkit-overflow-scrolling: touch‘ that contains many images that are scaled from 100px width to 50px width.
When combining this with forced hardware acceleration it will cause a massive drop in fps while scrolling.

Try it yourself by pointing your mobile browser to the following urls:
Images Example Version 1: http://goo.gl/XIn9e – NOT hardware accelerated, very good framerate
Images Example Version 2: http://goo.gl/DKC1u  - hardware accelerated, low framerate while scrolling, however seems not to affect the execution of JS as the displayed fps does not drop

The only difference between Version 1 and Version 2 is:

img {
 -webkit-transform: translateZ(0);
 -webkit-perspective: 1000;
 -webkit-backface-visibility: hidden;
}

The examples with HTMLImages shows a very huge drop in performance, however this effect is not solely limited to images but also <div> and other elements, even though it takes a larger number of divs to bring down the performance this way, it is possible:

Divs Example Version 1: http://goo.gl/1iF71 – NOT accelerated, fluid, high fps
Divs Example Version 2: http://goo.gl/qkdwm – accelerated, less frames on scrolling, seems to affect the execution speed of JS code

So bottom line: Forced hardware acceleration and ‘-webkit-overflow-scrolling: touch;’ do not work together very well!

1. Not all CSS Properties trigger hardware acceleration any more

Previously there were quite a few properties that triggered a hardware acceleration, for example:

• -webik-transform: translate3d(x,y,z);
• -webkit-transform: preserve-3d;
• …

As Apple states in its Developer Changelog for iOS6: ‘WebKit no longer always creates hardware-accelerated layers for elements with the -webkit-transform: preserve-3d option.[…]‘ There is a need for new CSS properties to trigger the acceleration, unfortunately I’m not aware of any official document by Apple listing those properties.

How to fix it:
Here are three properties that have been proven to work (at least in combination, I have not yet tested them solo, but they should):

• -webkit-transform: translateZ(0);
• -webkit-perspective: 1000;
• -webkit-backface-visibility: hidden;
  

As this is going to trigger hardware acceleration for the specified elements this might still not completely fix all the issues, therefore please continue reading Nr.2.

2. Overlapping with other Elements

Since I cannot downgrade to iOS5 I cannot say for sure if this “issue” already persisted, however it heavily persists with iOS6:

If you have an element(Element A) that is hardware accelerated and animated, it will/might cause performance and visual issues when overlapping with other elements(Element B) that are not hardware accelerated, as Element A will trigger Element B to be re-rendered with every change of Element A(at the end of a CSS-transition or when updating CSS properties through JS), which will cause:

• flickering of Element B, since it renders a lot slower
• heavy slowdown of the animation, since it needs more CPU time to render leaving less time for JS execution

One thing I noticed: If Element A OVERlaps another element it is not slowing down the animation as heavy as if Element A was UNDERlapping another element. Also it does not really matter if the parent-container of Element A has ‘overflow: hidden;’ or ‘overflow: visible;’ – it still slows doen the execution if the overlapping occures outside the bounds of the parent container.

How to fix it:
 a) This can be simply fixed by giving ALL overlapping elements the CSS properties that trigger hardware accerleration. (see 1.)
(My first approach to fix this was by alternating the DOM-order to only have OVERlapping elements, however fix a) is way easier and works way better – for me.)

I have visualized this here:

edit1: 16-10-2012

3. Avoid changes between ‘display: none;’ and ‘display: something;’

Changing the display-state on iOS is like adding or removing an element to and from the DOM and is therefor a very heady calculation depending on how many items you have in your DOM that can easyly cause the UI to freeze for a second or more.

How to fix it:
Instead of using the display-property, use the tranform-property instead, if you want to hide an item you can use something like this: transform:

translate(100000px,100000px);

and if you want to show the element, just set the values to 0:

translate(0px,0px);

You have to set the ‘position: absolute;’ though. This method needs a little bit more work than using ‘display’, however the performance of your webapp will thank you greatly for that.

I hope this helps someone as I was struggeling with this issue for quite a while, thoughts or additions on this article are very welcome!