dojox mobile scrolling is very choppy.

[Chris Mitchell]

reported by Brian Burns:

Scrolling become very choppy when a ScrollableView? becomes long than double the screen height. For example when running test_iPhone-ScrollableView?-demo.html one can add about 50 more rows to the categories page and the scrolling does not scale well.

Running on ipad.

[Chris Mitchell]

To really fix this for large lists, a paging/caching datastore will need to be used. It's similar to problems seen with grid pre-virtual paging. need to avoid lots of dom node creation...webkit will get to the point where it begins to checkerboard. Look at any long webpage to see this effect. I opened a new enhancement ticket for 1.8 to support virtual scrolling of the dojox.mobile lists, and there's also a gridx project for 1.8 that will support this for mobile use cases.

[Adam Peller]

Milestone still says 1.7... is this a 1.8 item? @chrism, where's the enhancement ticket?

[tracyhut]

Chris, this needs to be 1.7 right? Please confirm.

[Chris Mitchell]

This defect is to address scrolling problems with the current implementation in 1.7. For 1.8 we need to address virtual scrollling via stores. I could not find the enhancement ticket for 1.8, so I created #13789 to track that work.

[Chris Mitchell]

The original problem this ticket was opened for was a scenario with 200 list items being slow on iOS. That problem has been fixed, and the testcase dojox/mobile/tests/test_iPhone-ScrollableView?-demo-long.html was added to verify ~200 item lists. Any list bigger than that should resort to dynamic loading, paging or virtual scrolling solution (which are not automatically supported). Take a look at mobileFileBrowser demo for an example using dynamically loaded content from a server using a tree model.

A new problem scenario is being reported with ~50 form elements, not a list. Waiting for test case from customer to reproduce.

[ykami]

In [26420]:

Refs #12869 !strict Stopped subscribing to the resizeAll topic from ListItem? to call layoutVariableHeight(), and call it from the list widget instead. It looks dojo pub/sub is costly, and use of it from each ListItem? significantly degrades performance. By this change, tab switching in test_iPhone-ScrollableView?-demo-long.html will become more responsive.

[ykami]

In [26421]:

Refs #12869 !strict Create keyframes in init() rather than create them in a lazy manner. This could remove a slight delay that occurs when you start scrolling for the first time.

[ykami]

In [26426]:

Refs #12869 !strict Added keepScrollPos="false" to View. This might improve transition performance a little.

[ykami]

In [26427]:

Refs #12869 !strict Do not call resizeAll() for the target view on transition if already called once.

[ykami]

In [26428]:

Refs #12869 !strict keepScrollPos for ScrollableView? should be false.

[ykami]

In [26429]:

Refs #12869 !strict Search the styles sheets for DOM button to know how many DIVs are necessary for the DOM button, and create only a minimum number of DIVs.

[ykami]

In [26430]:

Refs #12869 !strict Reduced the number of DIVs created for ListItem?. This could improve scrolling performance at least on iOS. For iOS, it looks the number of DOM elements on a scrolling pane is a major factor for scrolling performance.

[ykami]

In [26448]:

Refs #12869 !strict Call of setKeyframes() must be in the if(has('webkit')) block.

[ykami]

In [26492]:

Refs #12869 !strict. Do not create an icon wrapper div unless icon is specified.