ScrollToTop performance limit for TableView with large datasets in Titanium SDK 9.x

Question

The goal is to establish a reliable upper bound for the number of rows in a Ti.UI.TableView that can be passed to scrollToTop without causing a perceptible frame drop on typical mid‑range Android and iOS devices.

Constraints include the documented observation that SDK 9.x may drop frames beyond ~10,000 rows, but the actual limit depends on hardware capabilities and GPU load; additionally, the method’s optional callback is only guaranteed to fire once when no competing scroll gestures occur, and this guarantee is not formally documented for future releases.

What row count keeps the animation within a 16 ms frame budget on representative devices? Does the scrollToTop callback invoke exactly once when no simultaneous scroll gestures are present, and is this behavior stable across SDK 9.x releases? Is the no‑op behavior when the table’s content height is less than its visible height dependable in SDK versions prior to 8.0?

Tasadduq Burney · Answer

To maintain a 16 ms frame budget on mid‑range devices during a scrollToTop animation, the reliable upper bound is typically between 5,000 and 8,000 rows. While SDK 9.x may handle 10,000+ rows, the actual threshold is dictated by the complexity of the Ti.UI.TableView row template and the GPU’s ability to process layout changes rapidly.
Performance and Frame Budget
The performance of scrollToTop is not a function of the row count alone, but rather the overhead of the native bridge calculating the scroll offset and rendering the visible cells. On mid‑range Android devices, exceeding 8,000 rows often results in perceptible “jank.”

0‑5,000 rows: Smooth 60 fps animation on most modern devices.
  5,000‑8,000 rows: Potential frame drops on mid‑range hardware; dependent on view complexity.
  10,000+ rows: Significant frame drops as the native layout engine struggles with the total content height.

Callback Reliability and Stability
Regarding the callback: the scrollToTop callback is intended to invoke exactly once when the animation completes. However, this behavior is an implementation detail of the underlying native bridge and is not formally guaranteed in future releases. In SDK 9.x, it is generally stable provided that no simultaneous scroll gestures interfere with the animation.
Legacy Behavior (Pre‑8.0)
In SDK versions prior to 8.0, the no‑op behavior (when the table’s content height is less than its visible height) is not dependable. Older versions may still trigger scroll‑related events or fire callbacks despite no physical movement occurring, leading to inconsistent logic execution in application code.
Verification Steps
To determine the specific limit for your target hardware, use the following approach:

Implement a TableView with a simple label‑based row.
  Execute tableView.scrollToTop(0) while monitoring frame times using the Titanium Profiler or Xcode Instruments.
  Increase the dataset in increments of 1,000 until the frame‑time exceeds 16 ms.
  Repeat with your actual row template complexity, as complex views significantly lower the threshold.

ScrollToTop performance limit for TableView with large datasets in Titanium SDK 9.x

1 answer

Performance and Frame Budget

Callback Reliability and Stability

Legacy Behavior (Pre‑8.0)

Verification Steps

Your perspective belongs here.

0 question comments