jQuery Forum

There have been persistent reports of poor performance when scrolling lists on touchscreen devices. These reports go back more than a year. See here:


The issue has been acknowledged:


... and much work has been done recently on improving performance in general. And, yet, the problem persists.

I think I have identified just what the problem is, have a simple work-around, and want to foster a discussion about a more complete/permanent solution.

In my experience, the problem occurs only with lists whose items are links. That is, the items are clickable/tappable with the content wrapped in an <a> tag. On most mobile touchscreen devices, performance of these types of lists is abysmal.  Frankly, it's just unacceptable. I would be embarrassed to release an app or web site with this kind of list performance.

There is no problem with lists whose items are NOT links. They scroll quite nicely, at least on the devices on which I have tested. (Admittedly limited - iPhone 4 and 4S, iPad 1.)

Proposed solutions have often revolved around specific enhancements - typically shadows, box-shadows, and gradients - and have involved removing these from list items.

Todd's comments (in the second link above) got me thinking about what is really going on here, and I think I've figured it out. It's really quite simple.

JQM essentially turns each list item in this situation into a button. And that button has up/down/hover states. JQM adds and removes styles to the items when they are touched, or clicked/hovered with a mouse. And that, in a nutshell, is the problem.

People have different styles of scrolling with a finger-swipe. There are slow, careful swipers. And there are fast, sloppy swipers. And there are those who "flick" and treat the screen like a trackball. The slow, careful swipers have less trouble. The flickers have the most. (Thanks, Todd, for your observations, which made this clear to me. No, as you reluctantly admit - it's unreasonable to ask users to change their scrolling style.)

The other clue was that I was seeing the problem using either a standard full-page scroll, or when using iScroll to create a scrolling region. If JQM has a problem with scrolling, iScroll should surely fix it right? I mean, if I can demonstrate that iScroll has great performance on my device, I should be able to use it with JQM and it should still have good performance. But it doesn't. iScroll doesn't fix it, because JQM is still doing all that button-state changing!

So, what is happening as you scroll is that you are changing the up/down/hover states of "buttons" (list items) that you touch. Because of different swipe styles, as well as the effect of kinetic/elastic scrolling on many devices, you may activate several "buttons" while you are swiping. (With kinetic scrolling, your finger will "slip" relative to the items.) You can see this clearly in the distracting visual effects as you scroll. You will see a "piano key" effect - on a fast device - and a horrible mess on a slower one.

Depending on how complex the styling, this will slow things down either a little or a lot, as the poor little CPU in the mobile device tries to keep-up with all those events. JQM is busy flipping styles around, and the browser is trying it's best to keep up with it. Unfortunately, most/all of this is going on in the CPU, and so any hardware acceleration goes largely out the window.

Not only does this slow things down, but it's a horrible visual distraction. What useful purpose does all that piano-key nonsense serve? I say "none".

So, here, really is the fundamental issue. It's inappropriate to use up/down/hover states on list items. At least not whilst scrolling. It serves no useful purpose, it's slow and it's visually distracting.

Fortunately, (at least for mobile touchscreen app developers, like myself) there is a quick and simple workaround. Just a bit of CSS to make it go away:

*.ui-listview *.ui-btn-up-c,
*.ui-listview *.ui-btn-down-c,
*.ui-listview *.ui-btn-hover-c
  {
  /* Copy your .ui-btn-up styles here */
  }

/* Repeat for each of your themes */

If you make ALL of the styles the same for up/down/hover you will see near-native performance. Even so much as a different border will impact performance drastically. Make all the styles the same for all of these states, and the visual distraction goes away. The CPU time needed to do all that redrawing goes away. The user is much happier. The developer isn't embarrassed to release the app.

(On most platforms at least) the issue is NOT shadows or gradients. Feel free to use them. The browser is just pushing around a bunch of pixels when you scroll, and in many cases now with hardware acceleration. The complexity of the styling affects only the initial drawing time, not scrolling performance.

Now, my workaround is only good for a pure touchscreen application. That's fine with me, but others are developing websites that target multiple devices. The effects are appropriate when using a mouse. They might even be desirable on a touchsceen - just not while scrolling!

Perhaps my CSS workaround can be combined with media queries, so that it will only apply if a touchscreen is in use?

However, I am concerned that there are still CPU cycles being wasted because JQM is still flipping the styles, though at least now the browser is saved from doing all that updating of the screen. I don't know if that's a lot of CPU cycles or just a few. But perhaps further improvement can be made.

The best solution, it seems to me, would be to somehow disable these events once scrolling starts. I don't know if that would require modification of JQM, or if it's something that can be easily implemented by a developer using unmodified JQM. It wouldn't be good if you have to add a ton of code to work-around this issue. There should be some clean, permanent solution.

I'll leave it to others to work-out what that solution is. I have mine. But I thought I'd share my findings and try to start a discussion about how to fix this in a broader sense.

--------

Now, there's  still something bothering me about this: the performance is not as bad on the JQM demo/doc site as in my own app. That is, on the same device, I can point Mobile Safari at the demo site, and while the performance is not great, it is also not horrible. In my app it is horrible. I looked for differences, I tested using only the distribution CSS (no additional CSS). And, still, the difference. It gets REALLY bad if you used data-inset="true".

The only difference I could find is the use of <nav></nav> around the <ul>. So, I added that, and no difference.

I can only speculate there is some difference between using the Safari app on iOS and embedding the platform WebKit control in an app. I understand there may be a difference in Javascript speed between the two. Perhaps there are other issues as well. (Hardware acceleration.) Curiously, though, the problem occurs on both an iPhone4 with iOS 4.3.5 and  iPhone 4S with ioS 5.01. And I *think* read that the Javascript issues was fixed in 5.0.

See below link. Apparently, the "Nitro" Javascript acceleration is unavailable to apps and only used by the Mobile Safari app. At least in 4.3, which is when it was introduced:

http://www.tuaw.com/2011/03/18/apple-confirms-some-webkit-optimizations-unavailable-to-ios-apps/

I want to be able to do transitions on page elements. That is, similar to the way JQM does page transitions, but just on an element within a page. Specifically, I want to replace the content of a listview - display a new list while giving the user some obvious feedback that the list is being replaced. I might like to use a slide or flip transition, for example.

BTW, I won't be needing the old content once the new content is shown. It's not a rotating "slide show" etc. - just bringing in new content to replace old.

I only need to support WebKit browsers, as this is for a mobile application (using Rhodes) and I only need to support iOS and Android. However, for the benefit of others, feel free to discuss solutions for other browsers.

I've had surprisingly little luck searching for this, probably because I don't know the right terms to search for.

I don't believe that JQM currently offers any support for this. (Please let me know if this is incorrect.) It seems, though, that there must be some code used to do page transitions that could be leveraged for this, and so I'd hope to see it as a feature in the future.

I can see how underlying JQuery features could be used to do certain simple transitions, such as fade out/fade in. I'm not sure how to approach something more complex, like a slide transition. It's clear I'd have to load the new list into the document and hide it initially. I imagine a slide, for example, would involve positioning the new list adjacent to the old one, and transition between classes that would change the positions and clipping of the two lists.

In my case (WebKit) is this just a matter of CSS3/HTML5 and no need for any JQ/JQM involvement at all?

Appreciate any pointers and discussion of alternative approaches.

Hey, I know this sore subject has been brought up before, but it seems to be going in one (or many) ear(s) and out the other.

There is a crying need for real programmer's documentation for JQM. By this, I mean an organized list of methods and attributes and descriptive text about actions and side-effects. In other words, something like the documentation available for JQuery itself.

There are little bits and pieces of that within the demo, but they are hard to find, scattered, and I don't get the sense that it is anywhere near complete.

It seems as if the current JQM documentation is for web designers, not programmers. And the JQ documentation is for programmers, not web designers. Can the twain meet? Is there any hope of this happening?

What is there it falls short, because it really isn't very accessible. While there is some descriptive text, for the most part the only way to find out how to do anything with HTML/CSS is to examine page source on the demo, and to add insult to injury, it isn't even possible to do that with a simple "view source". Because of the way JQM is structured, you have to use a tool like FireBug or Web Inspector to see what classes JQM has decorated the markup with. It would be really helpful to have some written documentation on CSS classes that are inserted into the DOM.

From the docs in the demo, I have NO idea of how JQM relates to JQ. How I would use JQ methods when working with JQM. As an example, I want to force the browser to scroll to the bottom of a list when an item is added. I have some vague idea that I ought to use $.mobile.silentScroll(). But then I have no idea how I might compute a position to pass to silentScroll().

Is there documentation available that I just don't know about? Third-party documentation? I know there are a couple of books, but of course they are already out of date. Is the project just waiting for an author to dig through the source code and do the job? The problem is, unless you find a generous author, you won't be able to take that copyrighted material and make it available as project documentation.

Sorry, I know I am going to ruffle some feathers with this post. I appreciate the hard work that has gone into JQM, and it's looking very promising. The scary thing is, this is a beta-level product that is being RAPIDLY adopted in production by many. With practically zero documentation. The issue has been brought up before, I see, for months, and just swept back under the rug.

Don't tell me to contribute. I'm not the guy. I'm not a heavy Javascript developer (I do most of my work in Ruby). I'm not the guy to dig through the source and make sense of it. (However, I'd be happy to help with editing once the raw data-mining has been done...)

I