The next application is the plain list from the Kitchen Sink ST2 look how bad it is from 0:34.
Lag builds up and it is very hard to use lists on Android 4 with ST2 because its only smooth if you scroll fast. If the tpl is more complex (like the first app, its much worse).
So there must be something you guys can do when you have a better performing list in ST1 than ST2. (When talking Android 4)
so there is hope...! I was about abandoning Touch because of this performance issue on ICS. Very much looking forward to a statement from Sencha. Thank you hotdp for bringing this up!!
It is also a deal breaker for us and I really hope there will be a fix fast. It is very hard to explain to a customer that our old solutions (ST1) is running smooth but after "upgrading" to ST2 it is worse.
Let me go over a few items here so you can understand where this (and some other) performance issues are currently. Warning: incoming wall of text...
In General - Layouts
There are layout related issues that are contributing to some of the problems you are seeing where the CSS is doing too much work and we need to do a better job of isolating panels and provide more layout information that we know about to the browser so it can isolate better. This problem affects all devices and is seen in more complex applications and any time you nest layouts. We have a prototyped solution to this issue and it will be part of the 2.1 release. The API impact of this is rather minimal and it will be very deep in the layout code where we don't see too many developers having to tinker with. We are going to change some of the DOM around slightly and we're trying to make the impact of this change on developers as minimal as possible. The good news is the impact is quite dramatic and should go a long way toward making the user HTML experience as good as it can be.
A bit more specific to Android ICS
As I hope most devs are aware, we opened an issue with Google back in February (http://code.google.com/p/android/issues/detail?id=25147) which demonstrated a serious issue in ICS when changing the compositing of any item. Finally, on June 2 we received a response from the Android team to the problem. We have had a good back and forth with them and they have acknowledged the issue and have said "We are aware of the problem and hope to improve things in an upcoming release." In the meantime they gave some suggestions on things we can do and said the the currently available 4.0.4 release fixes a serious painting problem which is indirectly related to this issue. We have tested the painting 'workaround' previously and it wasn't a viable solution to the problem. Upon hearing that the painting issue was resolved we went back and tried again and the results are very encouraging. By keeping a set of elements permanently composited and changing their contents, we can now get an aceptable experience. This can help in many common areas and some transitions if done correctly, so for the first time we now have an existing ICS version (4.0.4) with a way to workaround some (though not all) of these problems. In addition, it looks like the Android team is taking the issue seriously and committing resources to resolving it.
Lists in 2.1
For the next release (2.1), we have been preparing some changes to DataView/List which will fundamentally change how lists work and provide seamless access to large data sets. A list backed by a Store of 10,000 items will no longer be a problem and not be slower than a list with 10 items in it. The first iteration of this will require a fixed size to the items in the list and fixed header sizing. Though this limitation should go away in a later version. The interesting thing is how well this approach fits in with what is necessary for 4.0.4 ICS. It was almost custom made for it and lists are quite fluid on ICS using this approach.
Some other specifics to your specific issue is that we do see the poor performance in the Kitchen Sink lists, but it isn't as pronounced in the external version of the same list (the standalone list example and Tweet example). We are investigating the causes of this though we believe it to be related to the layout problem I mentioned earlier.
Now for some general timeframes (these are guesstimates and subject to a lot of change). The performance improvements mentioned here are currently being done outside of our normal branches, but we believe them to be complete and working well. Before we merge them in, we are reworking our measurement and testing tools to be sure we are covering as many possible scenarios as we can think of and be sure that things not only work correctly, but are faster. So it is a few weeks to have that in place before we start the port of the changes into the main code branch and then a couple weeks for the merge to happen. Once that happens we want to put that out in the 2.1 beta cycle for everyone to try out and give us feedback. Between now and then we want to give you access to the 2.1 Charts and the new List implementation as soon as we can (probably in that order). Charts is still a little rough around the edges, but the performance improvement is quite dramatic and you will see them very soon. Lists shortly after that, then the layout changes. Of course during this time we continue to work on other issues and a 2.0.2 release is pending within the next couple of weeks as well.