Android 4 list is performing worse in ST2 then ST1 (slow scroll)

[hotdp]

Hi,
Look here:
http://www.youtube.com/watch?v=tKwE669LIT8
The first App is a ST1 app with advanced tpl's with buttons, images ect.
It has no problems at all with following my finger smoothly.

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)

[mitchellsimoens]

We will need to research this.

[ingo.hefti]

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!!

[hotdp]

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!!

No problem.
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.

[ingo.hefti]

bump!

[Jamie Avins]

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.

[ingo.hefti]

thanks Jamie, you made my day (well, night over here...)!
hopefully we will see the new stuff soon (especially the lists)

[hotdp]

Thank you Jamie,
Great with a good and thorough explanation.

I guess the "funny" thing is why it performs better in ST2?

Also I can confirm that "nesting" have a dramatic impact on the overall list performance. Only one tabpanel and one other container is enough.

So there might be a beta fix within weeks?

[Jamie Avins]

As soon as we can with at least of of the items I talked about. It's going to be a bit staggered with new features coming in with these releases.

[jweber]

Great to hear you guys are on top of this. Thanks for the detailed explanation.