1168832 - Scrolling performance (tiling?) is notably worse than Safari on iPad

Status: RESOLVED FIXED

(Firefox for iOS :: Browser, defect)

Description

[Darrin Henein [:darrin]]

Actual: On iPad, Quickly scrolling a page like http://people.mozilla.org/~dhenein/labs/co-browsing/ results in blank white webview for a short period, which shortly pops in the rendered page. 

Expected: As in Safari, no pop-in/out of the rendered page should be visible to the user.

Tested on: iPad Mini Retina

Comment 1

[Aaron Train [:aaronmt]]

I don't see this on my iPad Air (1st gen) in either Firefox or Safari, quickly scrolling will white-out the content div for a second but not the index on the left, so not the entire WebView.

Comment 2

[Darrin Henein [:darrin]]

Good clarification, the contents on the left do stay for me too, it's the scrollable area on the right that blanks out.

Comment 3

[Stephan Leroux [:sleroux]]

Attachment: PR https://github.com/mozilla/firefox-ios/pull/531

I've added a patch that reverts the change we made to the deceleration rate so it's back to the WKWebView's normal rate to see if this makes a difference.

Comment 4

[Stephan Leroux [:sleroux]]

I did a bit of research and what I'm seeing is that one of the reasons behind web view's having a faster than normal deceleration is to reduce the rendering load of rendering the web content as it's an expensive operation. This would explain the tiling problem we're seeing on larger screens that are scrolled down to fast like the iPad when we set the deceleration rate lower. Before I commit to anything I want to see if someone from the WebKit team can confirm. Also, as far as setting a deceleration between normal and fast, it looks like the scrollView API only accepts predetermined deceleration rates :( Any time I try to set a custom one it defaults to the Normal rate.

Comment 5

[Stephan Leroux [:sleroux]]

Since we can only use Normal or Fast deceleration rate we need to choose between the two evils of the faster deceleration (non-native scrolling), but having the web content render better or go with the slower deceleration (native-scrolling) and have cases where on larger displays + fast movement result in slower tiling performance. Ideas?

Comment 6

[Stephan Leroux [:sleroux]]

For now we'll keep the deceleration rate to the default FAST speed. I've opened https://bugzilla.mozilla.org/show_bug.cgi?id=1175604 to track the radar I've opened for allowing better rendering for WKWebView when the deceleration rate is set to NORMAL.