GitHub Issue | n/a |
Type | Bug |
Priority | Critical |
Status | Closed |
Resolution | Fixed |
Resolution Date | 2012-10-30T18:39:19.000+0000 |
Affected Version/s | n/a |
Fix Version/s | Release 3.0.0, Release 3.1.0, 2012 Sprint 22 Core, 2012 Sprint 22 |
Components | iOS |
Labels | core, developer-preview, ios, notable, qe-testadded, scroll, slow, tableview, triage |
Reporter | Martin Guillon |
Assignee | Max Stepanov |
Created | 2012-08-01T07:37:02.000+0000 |
Updated | 2012-12-04T18:51:53.000+0000 |
I am developing on the master branch (using my own fork).
Recently i realised that my application (tableview) got amazingly slow scrolling.
Investigating the problem i discovered that it was the pull request #2473 that broke it.
So i decided to create an example that would definitively show it.
I created a clone of the iphone gmail application.
The application, using sdk 2.0.2.GA or even 2.1.1.GA, works almost flawlessly. There s just a very little lag on the first scroll
Now if you compile and run it using master branch, you ll see that the scrolling (on my iphone 4 at least), is very very bad. It gets better as you keep scrolling back and forth. But it never gets as smooth as with older sdks.
I will take a look at this bug myself, but i really think we should correct this one.
I have put the test project as attachment (because of images).
I am sorry to bump this one, but i think it s critical on ios. this should really be looked at before any release of SDk including pull request 2473 https://github.com/appcelerator/titanium_mobile/pull/2473
I've been experience extreme tableView slowdowns on scrolling when using 3.0.0.v20121015133920 (regular tableView with Image Background). On 2.1.3 GA it goes smooth... I think it may be a regression case.
PR submitted https://github.com/appcelerator/titanium_mobile/pull/3260 TableView scrolling performance should be comparable to what it was in 2.1.3 while memory usage should remain stable and not increasing as number of rows displayed.
Thanks Max. That s one step forward. I just hope we wont stop there!
@max, will the PR also address TC-1384?
@Ingo, the other one is more like a feature request and not yet completely defined.
@Max i agree it s not completely defined, but please do not ignore it ;)
Martin, thanks. What I'm trying to ascertain is if the issue in TC-1384 is a regression from a previous version (i.e. it worked fine in 2.1.3 but not in 3.0.0), or if it's a way of making things faster than they are now.
No it s not a regression in any way! Just a thought on another way to implement it and thank you!
Any news on this one? 3.0.0 shouldn't be published with this performance issue... since it is critical, but I see the fix version set only for 3.1.x
@Ygor--we will address this for 3.0.0. Note the "merge-3.0.0" label which indicates it will be backported to 3.0.
Test case for non-matching row hierarchies:
Pull merged.
Closing as fixed. Verified and tested with: Titanium Studio, build: 3.0.0.201211301903 Titanium SDK, build: 3.0.0.v20121130200208 Devices: iPad mini iOS 6.0.1 iPad4 iOS 6.0 iPhone5 iOS 6.0