Titanium

[ALOY-460] ScrollableView with noticeable lag when swiping between views

GitHub Issuen/a
TypeBug
PriorityCritical
StatusResolved
ResolutionFixed
Resolution Date2013-01-18T16:48:59.000+0000
Affected Version/sAlloy 0.3.4
Fix Version/sAlloy 1.0.0, 2013 Sprint 02
ComponentsXML
Labelsn/a
ReporterEric Merriman
AssigneeUnknown
Created2013-01-10T13:18:36.000+0000
Updated2018-03-07T22:25:38.000+0000

Description

There is a noticeable lag when swiping between views, I have tried setting the cache, it does not work. When I convert the ScrollableView to a ScrollView, there is no lag. What is the difference in performance between the two? Why is a simple view with an image and a table causing performance issues when swiping. This is a blocking issue on a release to a client. We have spent hours trying to identify what is the exact UI element that is causing the problem. We built the simple test app to demonstrate the problem. Any guidance would be appreciated.

Attachments

FileDateSize
splitview_error.zip2013-01-10T13:18:36.000+000010258548
workbench.zip2013-01-14T12:22:38.000+00003644237

Comments

  1. Eric Merriman 2013-01-11 After some struggles, I think I understand and am seeing this behavior. If I am correct, this is a slower-rate swipe, at some point during the animation the UI lags. I originally tried swiping quickly and could not discern this. Occurs on: iPad iOS 4.3.5 iPad mini iOS 6.0 iPad 4th gen iOS 6.0.1 - Far less noticeable.
  2. Eric Merriman 2013-01-11 Clarity on my repro steps: 1) Install app on iPad (app is universal, but splitview requires iPad) 2) Launch app 3) swipe slowly to the next tableview 4) When the tableview data transitions off the screen and the new data appears, there is a lag in the animation
  3. Aaron K. Saunders 2013-01-11 Our client application has more complex table rows so the lag is visible always. In an attempt to simplify the test case I removes the extra code.
  4. Eric Merriman 2013-01-11 Thanks Aaron, we are doing some more investigation and I'll get back to you as soon as we have root cause.
  5. Eric Merriman 2013-01-14 This seems to only affect Alloy-generated code. Sabil put together some code using a common JS approach and there was no similar behavior. Moving to alloy component and attaching non-alloy sample called "workbench".
  6. Eric Merriman 2013-01-14 Non-alloy version of this app
  7. Tony Lukasavage 2013-01-18 OK guys, first thing I did was make the apps a 1 to 1 comparison, meaning they both had the same number of views in the ScrollableViews and the same number of rows in each TableView. For the sake of mentioning it, I used 3 ScrollableViews and 100 rows in each TableView. Testing with slow swipes I was able to see the "hitch" in transition between views with the Alloy version. It happens right at the half-way point, telling me that the "hitch" is occurring as it is passing control to the next view. It also takes longer for the initial load. I had a hunch this is caused by ALOY-455, so I hacked the alloy.js runtime module to _not_ add Backbone eventing to the proxies being generated. Sure enough, once I did that and re-ran everything, the performance of the Alloy-based app is now comparable to that of its traditional Titanium counterpart. tl;dr: ALOY-455 will fix this and is literally the first ticket I am working on after I release Alloy 0.3.5 today.
  8. Tony Lukasavage 2013-01-18 This issue is a result of ALOY-455, which has been resolved and will be present in Alloy 1.0.0.

JSON Source