dojox/mobile/ScrollableView: smoothness regression on iOS6

[Adrian Vasiliu]

As several users reported already, the scrolling behavior of dojox/mobile/ScrollableView suffers a regression under iOS6. This is about a slight pause in the scrolling at the end of the touch gesture.

[Adrian Vasiliu]

Reproduced on iPhone 4S under iOS6. Other users reported it for an iPad2/iOS6.

Workaround: this trouble goes away by setting scrollType:2 (top/left) on the ScrollableView (programmatically or declaratively). Of course, we will try to find a better solution.

Explanation: in Dojo 1.8, the default value of the property ScrollableView.scrollType is 0, in which case it switches automatically the scrolling mechanism depending on the platform. Roughly:

• On Android it relies on top/left style attributes (scrollType:2) for scrolling,
• On the other platforms (including iOS) it relies on -webkit-transform:translate3d(x,y,z) (scrollType:1).

Specifying scrollType:2 instead of the default scrollType:0 forces the use of the same mechanism on iOS than on the other platforms.

Notes:

• Apple iOS6's release notes say that webkit-transform: preserve-3d shouldn't be used anymore for getting hardware-accelerated layers for an element. However, in our case I it doesn't seem we rely on it.
• Some user claims on a forum that the same would hold -webkit-transform: translate3d(0,0,0). We do rely on it..., but apparently we do get hardware acceleration in the end (after the pause), so it's unclear whether this is related with our trouble.
• It's unclear what style setting is a reliable way for getting hardware-accelerated layers in iOS6.
• The real cause of the regression might be different...

[Adrian Vasiliu]

About the scrollType:2 workaround: with long lists, while it removes the "pause" effect, the speed and general smoothness are less good than they used to be on iOS5 with the default scrollType. Not really surprising, since this is why the default has been chosen this way for iOS...

A better solution is needed for iOS6. See also #16012, which explores the use of "native" scroll as an alternate solution. Other solutions may exist...

[Adrian Vasiliu]

Not completely sure that our issue is exactly the same, but there seem to be a lot of complaints about performance regressions of CSS3 operations in iOS6. The following pure JS/HTML/CSS3 test case (found in forums):

​http://bvgam.es/apple/

demonstrates that some CSS3 animations (here, based on translate3d) are significantly slower and less smooth on iOS6. It is even much slower on iPhone 4S/iOS6 than on iPhone 4/iOS4.3.3.

Among the workarounds suggested here and there, I have tested:

• replacing "translate3d(x,y,z)" by "translate(x,y) translateZ(z)"
• adding -webkit-perspective: 1000; and -webkit-backface-visibility: hidden;

but as others I have found that these do not do the trick...

[Eric Durocher]

The attached patch seems to fix the problem: it adds a new scrollType that uses -webkit-transition (instead of -webkit-animation) to perform the slide animation. This mode is activated by default only on iOS6 for now, it could probably be used on other devices too but this requires more testing. This new mode can be forced by setting scrollType to 3.

[Eric Durocher]

Use -webkit-transition instead of -webkit-animation on iOS6 - Eric Durocher (IBM, CCLA)

[cjolif]

In [29764]:

refs #16038, #16066. Fixes two ios6 issues. One with ScrollableView? and one with resizing when activating Safari full screen mode. Thanks Eric Durocher & Adrian Vasiliu (IBM, CCLA). !strict.

[cjolif]

In [29765]:

refs #16038, #16066. Fixes two ios6 issues. One with ScrollableView? and one with resizing when activating Safari full screen mode. Backport to 1.8 branch.Thanks Eric Durocher & Adrian Vasiliu (IBM, CCLA). !strict.

[Adrian Vasiliu]

iOS 6.0.1 is now out, and at a quick testing it appears the fix on our side is still useful.