PDA

View Full Version : [DUPE-177] List scrolling issue in 0.92



PTG
27 Jul 2010, 10:48 AM
There is something seriously wrong with the list since 0.92 on iphone, but it works fine in chrome (or is it just because it's a faster hardware ?)
The scrolling is a lot slower than 0.91 which was a huge improvement over 0.9.
It doesn't feel smooth at all and seems to freeze sometimes. I have to swipe my finger multiple times before it starts scrolling again.

I don't have much more informations unfortunately. But I wanted to see if more people have this issue ?

Jamie Avins
27 Jul 2010, 11:07 AM
Do you have the details on what is in your list? Some source of your issue would be helpful.

PTG
27 Jul 2010, 11:21 AM
I can reproduce it with the list example unmodified running on an ipod touch 1st gen. And again, it was fine with 0.91.

Jamie Avins
27 Jul 2010, 12:50 PM
Thanks for the update, also what iOS is it running?

PTG
28 Jul 2010, 1:14 AM
iOS 3.1.3

dbottillo
28 Jul 2010, 5:30 AM
also with my nexus one (froyo 2.2) now scrolling list is more slow then version 0.91!

TommyMaintz
28 Jul 2010, 5:29 PM
Are you both talking about the list example bundled in the SDK? The only real change we made was the addition of disclosure icons. If you disable those in the examples, is the list performance comparable to 0.91? The scroller hasn't changed that much between .91 and .92. And on the List only the way the headers are pinned during scrolling has changed, and should actually be faster than before.

jamesmethews
28 Jul 2010, 10:30 PM
I also have the same problem with my nexus one froyo 2.2 the scrolling list is slow as compared to the version 0.91!!!
Submit an Article (http://ezine.pk/?module=submit)

PTG
29 Jul 2010, 8:50 AM
Yes I'm talking about the example from the SDK.

I just tested without the disclosure icons. It's better but still slower than 0.91, it's not smooth.

There is also a weird little effect when you touch the list for the first time, it moves a bit to the right then back to the left, and I can see part of a second header under the floating header (both labeled "A"). That doesn't bother me much, it's just a small visual artifact.
Sometimes I can also see the previous group header on top of the current group (like A over B header). It happens when u scroll down slowly and both headers are at the top of the list, scroll down some more and they overlap in the wrong order. It doesn't happen when you scroll up.

TommyMaintz
2 Aug 2010, 1:41 PM
The reason that the performance significantly changed between 0.9.1 and 0.9.2 (although we didn't change much in the Scroller class itself) was that we added a lot of documentation, which increased the file size. This increased the compilation time of first time code execution, and thus the performance of the scroller. After switching out ext-touch-debug with ext-touch in the examples, everything started performing like before.

The reason Froyo didn't really suffer from this, is that they are using V8 engine, which compiles much faster, and thus the performance hit isn't that noticeable. The same applies to newer generation iPhones, which have better hardware specs and compiles faster.

We are currently investigating if the compilation time is related to the file size of the individual javascript file that the code exists in, or the total size of all the javascript on the page. If its the first, then we might have to split the framework into several files. If its the latter, then the only way to test actual performance is to use compressed and obfuscated javascript.

For now we have updated all examples to use ext-touch instead of ext-touch-debug, and we will keep you guys posted on further discoveries and developments regarding these issues. More details on the issue are below for the technically minded.

------------------

After lots of debugging, we determined that JavascriptCore (the Javascript engine used on iOS and Android 2.1) compiles functions right before they are executed for the first time (JIT). This is nothing new, and we were aware of this. What we didn't realize though, is that the compilation time is directly related to the Javascript file size. The following would happen:

User touches the screen for the first time
TouchEventManger fires touchstart event (compile)
Scroller executes onTouchStart (compile)
...etc...

On older generation iPhones and Android 2.1, this compilation time could add up to several hundreds of milliseconds. During this time, the browser wouldn't fire any touch events, and the native behavior (scrolling the whole page) would take over. Then when you start moving, the same thing happened again.

User moves finger
TouchEventManager fires touchmove (compile)
Scroller listens for touchmove and executes onTouchMove (compile)
TouchEventManager fires scroll for first time (compile)
Scroller fires onScroll (compile)
..etc.

During all this compiling, again the browser wouldn't fire any events and the native browser behavior would take over.

Jamie Avins
3 Aug 2010, 8:54 AM
Closing this issue as a dupe. Please reference http://www.sencha.com/forum/showthread.php?104155-OPEN-131-Android-Scrolling-Issues.