Move this topic
Why JQM touchscreen list scrolling performance stinks (and what to do about it?)
in Developing jQuery Mobile
•
9 years ago
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/
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/
Replies(68)
@watusiware I'd be interested in seeing just how terrible the performance is that you are mentioning above. Would it be possible to post a video so we can see what you're seeing? As you mentioned above, sometimes we don't see what others see because we all have different things going on in our markup/css. If you could send us the markup for a page that demonstrates this that would be great too.
And I could reproduce the same scrolling hiccups. Note that the event you listen for can be "touchstart", "touchend", or "touchmove" ... they all had the same effect of causing hiccups.
So one other nugget I wanted to share was that I looked into scrolling performance prior to us shipping 1.0 using long listview pages with about 400-500 list items. What I found was that just the mere placement of a touch handler at the document or body level was enough to make scrolling hiccup on iOS and Android.
To prove this, I simply took a static markup snapshot of the 400 listview items page, removed *ALL* script includes and added the following script:
<script> document.addEventListener("touchstart", function(){}, false); </script>
And I could reproduce the same scrolling hiccups. Note that the event you listen for can be "touchstart", "touchend", or "touchmove" ... they all had the same effect of causing hiccups.
Now regarding button states problem you mention, we actually toggle the button states on touch events because folks used to complain that touch feedback as they tapped buttons/listview items was really slow ... we used to give the feedback on mouse events, and as we all know, on these touch devices there is at least a 300msec delay between touchend and the generation of the synthetic mouse events. I suppose that if we really had to, we could go back to mouse events, but then we'll have a different set of unhappy folks.
I'd really like to work with folks to figure out why some pages exhibit scrolling problems and others don't.
- Kin
I'll do some videos as soon as I can find some duct tape to lash an iPhone to a tripod. 
I'll just use one of the standard demo pages. This particular problem doesn't seem sensitive to the size of the list. I can just add it to my app and disable all the CSS and JS other than the standard stuff.
The slowdown when using the WebKit control from an app vs the Mobile Safari app is WAY more than the 50% cited in articles I've read, but of course that 50% is an average. It might be that JQM is doing something that is particularly slow without the Nitro acceleration.

I'll just use one of the standard demo pages. This particular problem doesn't seem sensitive to the size of the list. I can just add it to my app and disable all the CSS and JS other than the standard stuff.
The slowdown when using the WebKit control from an app vs the Mobile Safari app is WAY more than the 50% cited in articles I've read, but of course that 50% is an average. It might be that JQM is doing something that is particularly slow without the Nitro acceleration.
Leave a comment on kinblas's reply
Thanks for the post! If you could post a demo page we could test out in the browser that compares the current jQM with your tweaks for us to test, that would be ideal. I was tinkering with this quite a bit and didn't see a diference when removing the button events, but maybe you did something a bit different. It was using the 400 item listview because it really gets slow on some devices.
Trust me, we want to get the best performance so helping us narrow the issue down is very helpful.
-t
..............................................
Todd Parker
jQuery Mobile & UI design lead
Partner, Filament Group Inc.
todd@filamentgroup.com
..............................................
Todd Parker
jQuery Mobile & UI design lead
Partner, Filament Group Inc.
todd@filamentgroup.com
Leave a comment on toddparker's reply
@watusiware
By the way, just for clarification, are you talking about continuously flick scrolling *WHILE* the viewport is already scrolling? Or are you talking about just dragging the viewport and then letting go?
When I mentioned the hiccuping above, I was specifically talking about the flick while scrolling case.
- Kin
Leave a comment on kinblas's reply
Interesting that you started this thread having only tested on iOS devices.
In my experience the big showstopper is Android. Performance in the browser of all the devices we've tested is significantly slower than iPhone - even some of the power-house devices like the Thunderbolt and Incredible II. Why? There is no hardware acceleration in the browser on Android 2.x - a serious problem for HTML5 developers.
Todd revealed that development of the ScrollView component was frozen a while back because of 'issues with forms in Android'.
Where iPhone scrolling is quite acceptable for our needs, on Android it is not. Removing the scroll-view component is a significant compromise to our UI design, which follows commonly accepted mobile layout standards. However, at this point, if we stay with HTML5 for Android (which we may not), we will have to strip back on functionality even more to make the application's responsiveness acceptable.
Question is: What did Sencha do and are there any limitations or drawbacks with their technique?
Leave a comment on redthree's reply
Android is a big problem for any framework and using any sort of JS-based scroller only exacerbates the problem and causes potential usability issues. If anything, we're looking at taking a lighter approach to styling and event binding to help smooth out scrolling in future versions. When JS-based scrollers are used, they need to hijack a lot of touch events which can make form elements hard to impossible to use and can suffer from performance issues when longer lists are used. At the moment, there is no magic bullet here. We can use native overflow for iOS5 but this is a bit slow on Android and Playbook. You can polyfill with a JS scroller for iOS4 and older Android/BB but if this isn't carefully targeted only to these platforms, you can completely break the experience on WP7, WebOS, Symbian, Opera Mobile/Mini, etc. -- it's a very complex problem nobody has cracked yet.
We're doing a lot of work in theses areas for the next release.
..............................................
Todd Parker
jQuery Mobile & UI design lead
Partner, Filament Group Inc.
todd@filamentgroup.com
..............................................
Todd Parker
jQuery Mobile & UI design lead
Partner, Filament Group Inc.
todd@filamentgroup.com
Leave a comment on toddparker's reply
Is it perhaps time to take a step back and introduce paging mode options (rather than scrolling) for deficient devices. I'm suggesting an option to choose tap to scroll rather than swipe to scroll. At least then we will have a fallback without having to totally give up on the concept.
This kind-a breaks the touch UI paradigm, but at the moment we're left with very few options to provide a uniform cross-platform interface, and it feels to me like a viable workaround is needed.
Todd, is the future looking brighter on Android with Ice Cream Sandwich?
Leave a comment on redthree's reply
I can confirm that list + scrolling + event handling + iphone does not work out for me as well.
For me the scrolling itself is fast enough, however when I swipe quickly, the item in the list turns darkgray (theme-c) and remains 'selected' however I cannot continue the swipe gesture and the list won't scroll any further. (Image 1)
However, when I hold my finger a little longer on an item, it turns dark gray AND a dark line above the item appears. Now I can either release my finger and select the item, or I can continue the swipe and still scroll with the item still selected. (Image 2)
I am not sure if this is related, but it seems that this behavior gets worse when my thumb begins the swipe on an empty area, rather then the <li> text or arrow icon.
For me the scrolling itself is fast enough, however when I swipe quickly, the item in the list turns darkgray (theme-c) and remains 'selected' however I cannot continue the swipe gesture and the list won't scroll any further. (Image 1)
However, when I hold my finger a little longer on an item, it turns dark gray AND a dark line above the item appears. Now I can either release my finger and select the item, or I can continue the swipe and still scroll with the item still selected. (Image 2)
I am not sure if this is related, but it seems that this behavior gets worse when my thumb begins the swipe on an empty area, rather then the <li> text or arrow icon.


Leave a comment on webpoacher's reply
When I remove the CSS hover item (.ui-btn-hover-c), the visual effect as described above disappears, but the described problem persists. It looks like some event handling procedure is interrupted and sliding stops working. Any suggestions I could try?
Leave a comment on webpoacher's reply
When I remove the CSS hover item (.ui-btn-hover-c), the visual effect as described above disappears, but the described problem persists. It looks like some event handling procedure is interrupted and sliding stops working. Any suggestions I could try?
Leave a comment on webpoacher's reply
Can you explain just what you mean by "remove the CSS hover item"?
If you were to simply remove the CSS for .ui-btn-hover-c from the base CSS file, that would not do the trick. You have to insure that the styles for .ui-btn-hover-c and .ui-btn-up-c are identical. That seems to make the sluggish behavior go away, at least for me.
The bit of CSS I put in the first post will do that (within lists), for all themes. Load it after all other CSS files.
If you were to simply remove the CSS for .ui-btn-hover-c from the base CSS file, that would not do the trick. You have to insure that the styles for .ui-btn-hover-c and .ui-btn-up-c are identical. That seems to make the sluggish behavior go away, at least for me.
The bit of CSS I put in the first post will do that (within lists), for all themes. Load it after all other CSS files.
Leave a comment on watusiware's reply
I think my issue is a little different in the sense that quick swiping doesn't work really well for me. The scrolling itself really improves when I apply your CSS trick, even now that i put back the images for each item in my list. (By the way I am testing in both the browser and in phonegap as well)
Update: we resolved both issues by removing the <a> tags from a list and replacing it with the following fragment:
Update: we resolved both issues by removing the <a> tags from a list and replacing it with the following fragment:
- jQuery('li.clickable').live('click tap', function(ev) {
jQuery(ev.currentTarget).ajaxClick();
});
Hey, tried to do this but it doesn't seem to work for me. I'm not working with a list but rather a bunch of images that have "a" tags around the img tag. I know it's the same issue because when I remove the "a" everything works great. Here is my basic setup:
<script>
jQuery('img.pics').live('click tap', function(ev) {
jQuery(ev.currentTarget).ajaxClick();
alert('testing');
});
</script>
<img target="#kidventure-island" class="pics" src="http://www.lcbcchurch.com/img/slideshow/kidmin4.jpg" width="156" height="74">
Any thoughts on why this isn't working?
Leave a comment on webpoacher's reply
wow, this works very well for me.
Thanks a lot!
Alex
Leave a comment on barbalex's reply
Hmmmm... I think this works simply because you no longer have the <a> tag. So, JQM won't try to change styles when you touch items.Update: we resolved both issues by removing the <a> tags from a list and replacing it with the following fragment:Copy codejQuery('li.clickable').live('click tap', function(ev) {
jQuery(ev.currentTarget).ajaxClick();
});
However, I see another advantage to this. You are using the tap event on touchscreen devices. This should avoid the 300mSec delay for click.
FYI,
As of jQuery 1.7, the .live() method is deprecated.
But you shouldn't switch from .live() to .on() as mobileinit event will not fire. Oh.
Leave a comment on watusiware's reply
A little update on my CSS patch: simply copying your ui-btn-up styles will cause a problem with split-button lists. This is because split-button lists use different borders on different sides, and my CSS would inappropriately override that.
The easy fix is for the border only, specify ONLY the border color (in the patch). Fortunately, nothing else about the border changes between up, down, and hover states.
i.e. border-color: #ccc rather than border: <bunch of stuff>
The easy fix is for the border only, specify ONLY the border color (in the patch). Fortunately, nothing else about the border changes between up, down, and hover states.
i.e. border-color: #ccc rather than border: <bunch of stuff>
Leave a comment on watusiware's reply
nice tips!
also without the <a> tag i'm minus a major headache: how to have buttons or input elements inside a <li><a>.
Thanks for sharing!
also without the <a> tag i'm minus a major headache: how to have buttons or input elements inside a <li><a>.
Thanks for sharing!
Leave a comment on frequent's reply
I found a unique solution to what I think is the same problem. Note my post here: https://forum.jquery.com/topic/solution-in-search-of-the-root-problem.
The fix I mention in this is simply to do this in a global JS:
$(document).bind("vmouseover", function () { });
Leave a comment on jkane001's reply
I have a slightly different situation than the majority of you. I have a large set of "img" tags wrapped in "a" tags that seems to be pretty choppy when I scroll. I removed the "a" tags and everything seemed to work fine. So I tried many of the fixes on this page but none of them seem to work. The css option is quite intriguing but I think the setup would be different in my case. Anyone know how I would use that, let me know. Thanks!
Leave a comment on nate8684's reply
Doesn't this solution also block the change of color you see when you actually select an item from the scrolling list before the load transition?
doug
Leave a comment on doug lerner's reply
Doesn't this solution also block the change of color you see when you actually select an item from the scrolling list before the load transition?
Which solution?
If you mean the CSS one: Yes, and no. It's your choice. If you want the change of color when you select an item, just don't include the "down" selector in the CSS selector.
I think on touch-screen devices, all the color change does is add more unnecessary delay. The user doesn't NEED confirmation that they pressed the button. Touch-screen is direct control (vs. indirect with mouse) - there's no ambiguity in the user's mind as to whether they touched the button or not.
But if you want the confirmation, you can have the confirmation, and you will still avoid the busy-ness as the user scrolls, which both uses CPU cycles and is visually-distracting.
Leave a comment on watusiware's reply
Well, on most touch screen apps, when you select something there is some sort of indication. For example, consider news apps.
If the "down" selector is not included in the CSS solution, then won't the color still change when scrolling because you've pressed down on one of the items in the list in order to scroll? Or because it is scrolling is that considered a hover?
Thanks,
doug
Leave a comment on doug lerner's reply
I think it's trending toward not having an indication. Look at the newer iOS apps from Apple. Reminders does not provide an indication. Older apps, such as Phone and Contacts do.Well, on most touch screen apps, when you select something there is some sort of indication. For example, consider news apps.
Faster is better. That's central to the iPhone philosophy. Get in, get what you want, get out.
That's a hover - and what creates the annoying and slow "piano keyboard" effect.If the "down" selector is not included in the CSS solution, then won't the color still change when scrolling because you've pressed down on one of the items in the list in order to scroll? Or because it is scrolling is that considered a hover?
"down" doesn't happen until you lift your finger "up".
Go figure.
Seriously, touch turns everything inside-out.
Leave a comment on watusiware's reply
Actually the iOS Reminders app does indicate when you touch an item in the list of reminders. I just tried it.
I will try some experiments with the hover setting.
Thanks,
doug
Leave a comment on doug lerner's reply
You're right, it does. It's a very subtle, light gray, and I didn't notice it initially. But notice how it doesn't delay the transition. You barely see it, because the transition starts as soon as you tap.Actually the iOS Reminders app does indicate when you touch an item in the list of reminders. I just tried it.
Leave a comment on watusiware's reply
The down transition doesn't really slow things down on my iPhone. Most transitions seem to work well on the iPhone.
I think what slows things down with scrolling with Jquery Mobile is having the "semi-fixed" toolbar in v1.0.1. If you scroll fast enough so the footer fixed toolbar doesn't have time to re-appear then scrolling is very fast. But if you pause after each scroll to glance at the items then scrolling is noticeably slowed down because of the time it takes for the footer/navbar to reappear.
Unfortunately v1.1 just makes things worse because on Android and older iOS devices you don't even get the "fixed toolbar" to reappear at the bottom of the screen. It's always way down at the end of the content which is really unacceptable UI behavior. (Plus the navbar select is unstable in v1.1). I hope those problems are fixed for 1.2 or I don't know what I'm going to do. Get stuck at v1.0.1 forever?!
I chose Jquery Mobile for this after first trying Sencha because I was getting so bogged down in the Sencha framework I was unable to actually get anything done. Jquery Mobile in contrast is conceptually very easy to use. I wonder if Sencha has this same problems though, or if the UI is overall more stable (like with the fixed toolbars and scrolling) on both iPhone and Android.
Thanks,
doug
Leave a comment on doug lerner's reply
@Doug - You can apply the 1.0 dynamic re-positioning behavior as a polyfill for platforms like iOS4 that don't support position:fixed - https://github.com/filamentgroup/jQuery-Mobile-FixedToolbar-Legacy-Polyfill
..............................................
Todd Parker
jQuery Mobile & UI design lead
Partner, Filament Group Inc.
todd@filamentgroup.com
True fixed toolbars are tricky to achieve with much cross-platform compatibility. Many frameworks like Sencha achieve this effect by writing a custom JS scroller to make the content area scrollable so the "fixed" toolbars can simply sit outside the scrolling region. Other than the performance hit of re-writing all the native scrolling logic in JS, the physics are the same across all platforms so it feels a bit off. Most importantly, these JS scrollers only work well in iOS and, to a lesser extent, Android and BB Playbook. On all other platforms, this can render the page completely inaccessible if this code isn't shielded from these other browsers. Even on platforms like Android where these work, the way they need to intercept touch events to manage scrolling can completely break form elements which is a big concern.
If you are building an app and targeting a more narrow set of platforms, using this type of approach may be a good solution and does improve both fixed headers and transitions but the physics and performance issues still need to be considered.
Jon (Watusiware, the fellow who started this thread) has created a way to use iScroll with jQuery Mobile and this might be worth looking at, it shaping up nicely:
In 1.1.0, we did get rid of the hover and down states on lists which does remove the annoying visual feedback as you scroll (I agree this was a problem). Do lists seem to performa any better for folks with this change in place?
Thanks!
Todd
..............................................
Todd Parker
jQuery Mobile & UI design lead
Partner, Filament Group Inc.
todd@filamentgroup.com
Leave a comment on toddparker's reply
Todd,
Thanks for your message. I will check those things out.
For me, there were several "show stoppers" preventing me from upgrading from 1.0.1 to 1.1.
The first was the "floating fixed" footer navbar no longer worked in Android (2.3.3) and older iOS devices. The behavior in 1.0.1 isn't ideal, but at least the footer doesn't have to be hunted down way at the bottom of the content! I still hope that would be the default behavior (for backwards compatibility) in 1.1, but anyway... I can look at some of those other solutions. Is there a reason that wasn't the default fallback behavior in 1.1? It affected so many devices!
Another really bad problem though is that the navbars (or button groups) in the fixed footer, even in iOS 5.1, are just plain less reliable in 1.1. On long pages where the content extends beyond the bottom of the screen, touching another tab will often simply not load the new page. This even happens when accessing the 1.1 demo pages, as I described in another thread.
In 1.0.1 however, touching the footer/navbar tabs always work and I don't get stuck on a page.
I'm guessing this has something to do with how new fixed footers are achieved in 1.1? Anyway, I think it's a serious usability/stability bug and is highly reproducible.
Thanks for all your work!
Regards,
doug
p.s. If you got rid of the down state in lists in 1.1 does that mean there is no longer a "selected" effect prior to the transition like there is in 1.0.1?
Leave a comment on doug lerner's reply
This doesn't seem to be the case. Am I misunderstanding you?In 1.1.0, we did get rid of the hover and down states on lists which does remove the annoying visual feedback as you scroll (I agree this was a problem). Do lists seem to performa any better for folks with this change in place?
I removed my CSS that makes the up/down/hover states for lists styled the same. When I press an item in a list, the item still turns blue before making the page transition.
It does appear, though, that the "hover" state is no longer being used when scrolling. I do not get the "piano key" effect while scrolling a list.
Actually, I DO still see the hover effect, but only when the list is not actively scrolling. If I press an item, I see the "hover" effect sometimes, and THEN it turns blue. Sometimes you see the hover, sometimes you don't.
As well, very occasionally, I will get the "down" effect (blue background) and then the page transition will not occur.
Unfortunately, there is still a variable delay of 2-4 seconds seconds (on iOS 4.3.5/iPhone 4) when pressing an item, and again a somewhat shorter delay after the item turns blue and you get a page transition. This would seem unrelated to the up/down/hover states, as this occurs on normal buttons as well.
The good news is that scrolling performance is good, even on iOS 4.3.5, without the "piano keyboarding".
Leave a comment on watusiware's reply
@watusiware - In 1.1, we added a configurable delay for touch devices to prevent the framework from adding the hover and down classes as you scroll to both improve scrolling performance and eliminate the piano key effect.
http://jquerymobile.com/test/docs/api/globalconfig.htmlSet the delay for touch devices to add the hover and down classes on touch interactions for buttons throughout the framework. Reducing the delay here results in a more responsive feeling ui, but will often result in the downstate being applied during page scrolling.
..............................................
Todd Parker
jQuery Mobile & UI design lead
Partner, Filament Group Inc.
todd@filamentgroup.com
buttonMarkup.hoverDelay
integer, default: 200Once you tap a list item, you may briefly see the hover state, but it should pretty much flip to the active (blue) state immediately when you tap to give you visual feedback that you selected an item. We need to wait for the mouse (click) event to bubble up to actually kick off the AJAX page navigation because if we bind to the touch events, it would be too easy to accidentally tap an item so there is a natural 300ms delay for that.
The 2-4 second delay seems really long but it depends on how complex your pages are because we need to load in the page via AJAX, enhance the content and kick off the animated transition. In the docs, most page load in 1-2 seconds, even on 3G. I'm assuming that these are external pages being pulled in via AJAX, not local pages in a multi-page setup - is that right?
Thanks,
Todd
Todd
..............................................
Todd Parker
jQuery Mobile & UI design lead
Partner, Filament Group Inc.
todd@filamentgroup.com
Leave a comment on toddparker's reply
Todd,
Have the developers given any thought as to why the navbars / grouped buttons in data-position="fixed" footers don't work well when there are lists which extend below the screen in v1.1? That happens often if you are at a tab with such a list; trying to go to another tab doesn't load the page.
This doesn't happen in v1.0.1 at all.
Thanks,
doug
Leave a comment on doug lerner's reply
apologies if i missed something
there seems to be loooads of replies flying around
is the list problem STILL a problem? i've only scan read the replies and can't see anyone saying: "yeeeha they've finally solved it! thank u god!"
i have a lost of 33 items all with links
seems to be ok (currently they all just link back to index.html - still developing)
this list will become 150 maybe
i'm getting worried that there will be problems
i just took it for granted there would be no problem
Leave a comment on omardesign's reply
@doug - Is there a issue number you're referring to?
..............................................
Todd Parker
jQuery Mobile & UI design lead
Partner, Filament Group Inc.
todd@filamentgroup.com
..............................................
Todd Parker
jQuery Mobile & UI design lead
Partner, Filament Group Inc.
todd@filamentgroup.com
Leave a comment on toddparker's reply
Todd,
No, just posts in this thread and another thread where this was being discussed. If it's best I open up an issue I can do that. Where might I do that?
Thanks,
doug
Leave a comment on doug lerner's reply
The GitHub issue tracker is the best place to report an issue. Please include a detail description and test page using the latest build. https://github.com/jquery/jquery-mobile/issues?milestone=&sort=created&state=open&utf8=%E2%9C%93
..............................................
Todd Parker
jQuery Mobile & UI design lead
Partner, Filament Group Inc.
todd@filamentgroup.com
..............................................
Todd Parker
jQuery Mobile & UI design lead
Partner, Filament Group Inc.
todd@filamentgroup.com
Leave a comment on toddparker's reply
Todd,
I entered the new issue.
After reviewing the threads, I see the bug is with the so-called "persistent toolbars" which somebody was suggesting I use on my Android because the data-position="fixed" toolbars don't fall back to the v1.0.1 behavior and so users don't see the toolbar on long lists.
But the persistent toolbars are unstable. From the issue I filed:
In v1.1, in Android 2.3.3, if there is a page with a long list (longer than the screen) containing a persistent navbar, very often you cannot click transition from one page to another.
You can reproduce this problem on your Android 2.3.3 device by going to http://jquerymobile.com/demos/1.1.0/docs/toolbars/footer-persist-d.html and click around on the four navbar items: friends, albums, emails and info.
Very often, after going to Friends if you then click on Albums, the Albums page does not load and you don't transition from Friends.
doug
Leave a comment on doug lerner's reply
The scrolling issues seem to be largely resolved, but has anyone addressed the click delay on the list items themselves?
On mobile devices, even using the doc's list performance test page http://jquerymobile.com/demos/1.1.0/docs/lists/lists-performance.html, scrolling seems OK, but if you click/tap any of the items, there is a 3-4 second delay before the button press is displayed and then another 1-2 seconds before the page transition occurs.
This is exacerbated by the size of the list, larger lists have worse performance.
Any thoughts on this?
Leave a comment on roof01's reply
I can confirm this, on iPhone 4S/iOS 5.1 I get the same terrible numbers on the performance test that you do. It's completely unusable. I can add the observation that the delay is greater the further down the list that you tap. In fact, if you tap far enough down the list, it will crash Mobile Safari.
Meanwhile, if you try the 1.0.1 list performance test, it is MUCH faster. I wouldn't say it's a speed demon - it's on the outer edge of acceptability. As well, it does NOT crash Mobile Safari. It is at least twice as fast as 1.1.0.
One other difference I notice is that on the 1.0.1 test, the "loading" icon shows much sooner, and remains on the screen longer. On the 1.1.0 test, at first I thought it didn't show at all, because it shows so briefly. So, on 1.0.1 at least the user has some feedback while they are waiting. On 1.1.0 you get the loading icon briefly, it goes away, and then you wait longer. On 1.0.1 once you get the icon, it stays until the new page starts to slide in. If you blink, you'll miss it on 1.1.0.
On several counts, 1.0.1 is superior to 1.1.0 for scrolling lists. 1.0.1 is better in just about any way you might judge it. There's just nothing right about how 1.1.0 handles this.
Of course, it's fine on a desktop. Anybody at JQM actually test on MOBILE devices?
It might be interesting to try some of the suggested performance tricks on the test page. I suspect the "force caching" trick will just make Mobile Safari crash sooner. I don't see a gradient on the test page, so removing gradients won't help. Removing down state could help.
Meanwhile, if you try the 1.0.1 list performance test, it is MUCH faster. I wouldn't say it's a speed demon - it's on the outer edge of acceptability. As well, it does NOT crash Mobile Safari. It is at least twice as fast as 1.1.0.
One other difference I notice is that on the 1.0.1 test, the "loading" icon shows much sooner, and remains on the screen longer. On the 1.1.0 test, at first I thought it didn't show at all, because it shows so briefly. So, on 1.0.1 at least the user has some feedback while they are waiting. On 1.1.0 you get the loading icon briefly, it goes away, and then you wait longer. On 1.0.1 once you get the icon, it stays until the new page starts to slide in. If you blink, you'll miss it on 1.1.0.
On several counts, 1.0.1 is superior to 1.1.0 for scrolling lists. 1.0.1 is better in just about any way you might judge it. There's just nothing right about how 1.1.0 handles this.
Of course, it's fine on a desktop. Anybody at JQM actually test on MOBILE devices?
It might be interesting to try some of the suggested performance tricks on the test page. I suspect the "force caching" trick will just make Mobile Safari crash sooner. I don't see a gradient on the test page, so removing gradients won't help. Removing down state could help.
Leave a comment on watusiware's reply
Hi all -
I can confirm what watusiware just flagged on the list performance page with a 4S. I won't take the bait on the other comments, but this is a performance regression that we're looking at now.
Is there an issue in the tracker for this? If so, please post that here. If not, please create a ticket.
Just a general reminder that a discussion here isn't the same as an issue report in the GitHub tracker. If you see a problem, please post a detailed report along with a test page using latest and we'll escalate things as they come in.
Thanks all,
Todd
..............................................
Todd Parker
jQuery Mobile & UI design lead
Partner, Filament Group Inc.
todd@filamentgroup.com
..............................................
Todd Parker
jQuery Mobile & UI design lead
Partner, Filament Group Inc.
todd@filamentgroup.com
Leave a comment on toddparker's reply
Thanks, I tried removing the ui-btn-down style and no improvement. Unfortunately I'd like to stay at 1.1 because of the improvements for the fixed headers and footers in 1.1.
I just entered a ticket for this....
Leave a comment on roof01's reply
Well, I have the same performance issue. Tested on ipad3 and on a HTC OneX with ICS.
I got a couple of different lists with 70 to 900 items in them linking to separate small pages for each list-item via a-tag.
Scrolling is fine even on the larger lists so I have no complaints there.
However - the delay from pressing a list-item/button to it 1/getting selected and then transition is the problem.
On the smaller lists (70 items) there is just a 1-2 second delay from you tap the item and it turns blue (in my theme) and then transitions over in a second. It's ok even though it would have been nicer with an even snappier respons.
The lists with around 180-360 items have a 4-6s delay before doing a quick transition.
The biggest list, with 900+ entries, takes a whopping 34 seconds from the time I click on an item until it lights up and then transitions.
So it's the big lists that really are affected ... I guess I have to split them up in sublists for now.
/B
Leave a comment on swedbear's reply
Hi everyone, thanks for your feedback and patience while we investigated this issue. It's a big problem but it escaped our testing for 1.1 because it's only an issue on very long pages when you click a link far down. After a ton of red herrings and alternate suggested fixes, we now understand the problem and are working on landing a fix to bring performance back to 1.0 levels. I reported the finding here:
..............................................
Todd Parker
jQuery Mobile & UI design lead
Partner, Filament Group Inc.
todd@filamentgroup.com
Pasting here for posterity:
Alight @scottjehl figured out the root of the issue here. In 1.0, we first scrolled to the top of the page before starting a transition. In 1.1, we wanted to avoid this jump so we now fade the page out first by default. As it turns out, devices like an iPhone seem to keep the page above your scroll position in memory when doing a transition, but not the part of the page below.
So if you're on a long, complex page like the listview performance page with 500 items, clicking the first list item will work pretty well, but one halfway down will be very slow and a bottom one will crash the browser. Why? Because the browser is trying to animate a really massively tall page when scrolled down due to how it handle things. Test here:http://jquerymobile.com/test/docs/lists/lists-performance.html
As a test, we added another condition to say that if you're either coming or going to a page where the scroll position is 3x the height of the device's screen, skip the transition. This makes the navigation back to it's snappy self. You'll notice we're using scroll position, not screen height here because I can navigate to a 10,000 pixel tall page fine but if I need to navigate away from that same page when scrolled down (or nav back to this with a scroll position restored), it will need way more memory to run the transition and could be slow or fail.
This 3x value is just a starting point, we can use whatever criteria we want. Here is the change to line 28 in jquery.mobile.transition.js to give this a spin:
none = !$.support.cssTransitions || maxTransitionOverride || !name || name === "none" || Math.max( $( window ).scrollTop(), toScroll ) > screenHeight * 3,
The question is how to layer this in. Do we just pick a value for this for 1.1.1 as a safely valve for performance now, then expose a config option for 1.2 to set the criteria? This is parallel to maxTransitionOverride
- this sets the screen width that shuts off transitions automatically, this new one is like ```maxTransitionScrollOverride''' where we nix transitions based on vertical scroll position. Naming could be cleaned up to make this clearer.
Note: I think the option name we're considering adding for this is ```maxScrollForTransiion```
..............................................
Todd Parker
jQuery Mobile & UI design lead
Partner, Filament Group Inc.
todd@filamentgroup.com
Leave a comment on toddparker's reply
Yay! Backwards compatibility on the horizon! :)
doug
Leave a comment on doug lerner's reply
i'm confused
i' read the last reply from @toddparker - is there a solution being suggested here?
do we need to edit the jqeurymobile.js file??
or should just follow @watusiware's solution given in his first post?
thanks
Leave a comment on omardesign's reply
It's a bit confusing, because there are three separate issues that commonly affect list performance. I think one of the reason fixing it has taken so long is that it wasn't initially clear that there were multiple issues.
The "piano key" effect was fixed in JQuery Mobile 1.1, and so if you are using 1.1 you don't need my CSS fix. It can be useful with 1.0.
In jquery.mobile.iscrollview, I use a different means for avoiding the piano key effect with jQuery Mobile 1.0.
As well, there are two performance bugs in listviews that have both been fixed and scheduled for release in 1.1.1.
The "piano key" effect was fixed in JQuery Mobile 1.1, and so if you are using 1.1 you don't need my CSS fix. It can be useful with 1.0.
In jquery.mobile.iscrollview, I use a different means for avoiding the piano key effect with jQuery Mobile 1.0.
As well, there are two performance bugs in listviews that have both been fixed and scheduled for release in 1.1.1.
Leave a comment on watusiware's reply
@watusiware thanks for the reply - really helpful
i've tried out the problem. i created a list of 300 items
when u click on an item nearer the bottom, the click response is several seconds
is there a solution to this problem?
is this what @toddparker's reply refers to?
if i can't fix, then i'll have to resort using a long html page - which will be ok, but really shouldn't be necessary
let me know
thanks
Leave a comment on omardesign's reply
when u click on an item nearer the bottom, the click response is several secondsis there a solution to this problem?is this what @toddparker's reply refers to?
Yes, that would be Issue #4340:
https://github.com/jquery/jquery-mobile/issues/4340#issuecomment-6497298
Leave a comment on watusiware's reply
I think everyone on this thread might find this interesting: https://github.com/jquery/jquery-mobile/issues/2107
For those don't feel like reading my long post in that github thread:
Add the following line in your mobileinit handler:
$(document).bind("mobileinit", function() {
...
$.event.special.swipe.scrollSupressionThreshold = 100;
...
});
As of v1.1.1, that is set to 10. So, each time your scroll up or down wanders 10px to the left or right, your scroll is being suppressed. Ugh. I don't know about anyone else, but I have trouble scrolling perfectly up or down in a perfectly straight up or down swipe.
Leave a comment on dcarrith's reply
and adding that bit of code fixes?
Leave a comment on omardesign's reply
It definitely fixes it on my Nexus 7 (cordova app and Chrome). That's all I've tested so far, but I'm guessing it should fix it in every browser and platform. That setting seems to be (at least partly) how JQM differentiates between a swipe left and right and a scroll up and down. And, the empirical evidence seems to support that assumption.
EDIT: well...It definitely fixes it on my Nexus 7 (cordova app and Chrome). Although, in the stock browser on GNex ICS, it doesn't seem to make a difference (although, listview scrolling performance is good overall either way).
Leave a comment on dcarrith's reply
I'm not able to demonstrate this on JQM 1.1.1 on iPhone 4 (iOS 4.3.5) or iPhone 4S (5.1). So, the iOS platform may not be affected.
I tested both using a conventional listview (with links) with no fixed header/footer, as well as with jquery.mobile.iscrollview. (I thought at first it might not affect iScroll, because I hadn't noticed this in my app, and iScroll does it's own detection of scrolling using touch events.)
I tested in Rhodes, which is a similar environment to PhoneGap (in that it uses a UIWebView).
In fact, I can swipe at a 45 degree angle from corner to corner with no problem.
I tested both using a conventional listview (with links) with no fixed header/footer, as well as with jquery.mobile.iscrollview. (I thought at first it might not affect iScroll, because I hadn't noticed this in my app, and iScroll does it's own detection of scrolling using touch events.)
I tested in Rhodes, which is a similar environment to PhoneGap (in that it uses a UIWebView).
In fact, I can swipe at a 45 degree angle from corner to corner with no problem.
Leave a comment on watusiware's reply
Re: [Developing jQuery Mobile] Why JQM touchscreen list scrolling performance stinks (and what to do about it?)
8 years ago
- via EMail-to-forum
I've been trying to reproduce this threshold improvement all day on various Android devices and can't. Maybe this only improves things in Cordova? See my comments in the linked issue.
Leave a comment on toddparker's reply
ok, even more confused now
previously: i thought it was only a problem on iphone
i tested on iphone with 300 - 600 items in the list
there was a massive delay to get a click response
(i wasnt aware that there was also a big scrolling problem)
on my android (htc desire) all seemed to be ok - using dolphin browser
my iphone: 3gs with latest version of the IOS (5.2 or something)
i dont think i actually want to spend time wasting with this to be honest :(
i think the best option will be to just use a long html page
this sucks majorly though
Leave a comment on omardesign's reply
Yeah, sorry folks. Although I'm certain it drastically improves scrolling performance of a Cordova version of my app on a Nexus 7 running 4.1.1, I'm having trouble seeing it make a difference anywhere else. I thought it was making a similarly noticeable difference in Chrome on a Galaxy Nexus running 4.0.4 as well as Chrome on 4.1.1, but now I'm not so sure. I'll keep testing. I'll be interested to see if the scrollSuppressionThreshold makes a difference for scrolling performance for anyone else on any other platforms or browsers. I have quite a few other devices too, so I'll try to run some tests later.
Leave a comment on dcarrith's reply
Okay, so it seems the list scrolling performance improvement that is realized by overriding and setting $.event.special.swipe.scrollSupressionThreshold to 100 (or even 30, 50, or anything more than 30 or so) is only realized if you happen to be binding to swipeleft and swiperight (thanks to @jblas for that epiphany). If you are, then try to increase the scrollSupressionThreshold and see if it helps your list scrolling performance. It does for me on a Nexus 7 as well as a Galaxy Nexus (Cordova app and in Chrome for sure).
If you are not binding to swipeleft and swiperight, and you are having listview scrolling performance issues, then some of the other tricks mentioned in this thread (and others) will certainly help. I had already put most of the improvements in place and was still seeing abysmal scrolling performance (on certain devices) and couldn't figure out why. But, I think this is it.
Leave a comment on dcarrith's reply
Just found this page, recommending to set
- .scrolling-element-class .child-element {position: relative;-webkit-transform: translate3d(0,0,0);}
My giant form went from 1sec delay to start scrolling to me thinking how to slow down scrolling.
Anyone else tried this? Caveats?
Anyone else tried this? Caveats?
Leave a comment on frequent's reply
Yes, I've been doing something like this for some time. I use translateZ(0), but you can use any 3D identity transform.
I haven't seen the position:relative recommendation before, though. That's a new one on me. I will do some testing to see if it does anything.
Originally, I used a * selector, as recommended by Mateo, the author of iScroll. But after experimenting, I found it was only needed to apply this to the top-level elements. So, if you are scrolling a listview, you can just apply this to the <li> elements.
Both perform the same when scrolling. The difference is it is very expensive up-front to use the * selector. In my case, it doubled the initial rendering time of the page to use *, and gains nothing in scrolling performance.
Somewhat related, I use this on page transitions as well.
.ui-page,
.ui-page > div {
-webkit-transform: translateZ(0);
}
I haven't determined definitively if the first selector above is needed. I found for scrolling lists with iScroll, it is not:
.iscroll-content li {
-webkit-transform: translateZ(0);
}
But it seems to make things smoother for page transitions to also apply it to .ui-page, and doesn't seem to cost anything.
For iScroll, I probably should apply a class to the list elements, and use the class in the selector, as this should be more efficient than an element selector. As, well, I suppose a better choice would be something like:
.ui-page,
.ui-page .ui-header,
.ui-page .ui-footer,
.ui-page .ui-content {
-webkit-transform: translateZ(0);
}
Or make a single new class for top-level elements on a page.
I haven't seen the position:relative recommendation before, though. That's a new one on me. I will do some testing to see if it does anything.
Originally, I used a * selector, as recommended by Mateo, the author of iScroll. But after experimenting, I found it was only needed to apply this to the top-level elements. So, if you are scrolling a listview, you can just apply this to the <li> elements.
Both perform the same when scrolling. The difference is it is very expensive up-front to use the * selector. In my case, it doubled the initial rendering time of the page to use *, and gains nothing in scrolling performance.
Somewhat related, I use this on page transitions as well.
.ui-page,
.ui-page > div {
-webkit-transform: translateZ(0);
}
I haven't determined definitively if the first selector above is needed. I found for scrolling lists with iScroll, it is not:
.iscroll-content li {
-webkit-transform: translateZ(0);
}
But it seems to make things smoother for page transitions to also apply it to .ui-page, and doesn't seem to cost anything.
For iScroll, I probably should apply a class to the list elements, and use the class in the selector, as this should be more efficient than an element selector. As, well, I suppose a better choice would be something like:
.ui-page,
.ui-page .ui-header,
.ui-page .ui-footer,
.ui-page .ui-content {
-webkit-transform: translateZ(0);
}
Or make a single new class for top-level elements on a page.
Leave a comment on watusiware's reply
So are you applying it to the list itself or the list items? I'm also putting it on the page itself now.
I'm still trying out what works best. I spent the whole day trying to make my form scrollable (z-index layer, containing a ton of listviews - since I started using list items for inputs).
Initially the scrolling was dismal even after un-box-shadowing, removing gradients etc. There was lag of about half a second before the scrolling started. I didn't really find anything on scroll lag/stall/delay, so the above sure seems handy. Still a little skeptical though, if the page still works on Android.
So I'll be testing... Let me know what you find out about pos:relative, I'll post on Android.
Thanks for your hints.
I'm still trying out what works best. I spent the whole day trying to make my form scrollable (z-index layer, containing a ton of listviews - since I started using list items for inputs).
Initially the scrolling was dismal even after un-box-shadowing, removing gradients etc. There was lag of about half a second before the scrolling started. I didn't really find anything on scroll lag/stall/delay, so the above sure seems handy. Still a little skeptical though, if the page still works on Android.
So I'll be testing... Let me know what you find out about pos:relative, I'll post on Android.
Thanks for your hints.
Leave a comment on frequent's reply
My experience is it is only needed on the list items, not the list itself. But that is with iScroll, your experience may be different with another or no scrolling solution.
You can pretty clearly see what this is doing by first not applying it, and then scrolling down to the bottom of your list. Once you have scrolled down all the way to the bottom, scrolling is smooth after that.
iOS WebView apparently caches elements for hardware acceleration in some buffer as you are scrolling. Once it has seen the entire list, it is cached and then it is smooth.
The CSS moves the caching from as-you-go to up-front. You take a hit at page rendering, but hopefully the user does not notice. It helps if you also deal with click delay or other up-front issues. When you start scrolling, it is smooth from the start because the caching is already done.
You can pretty clearly see what this is doing by first not applying it, and then scrolling down to the bottom of your list. Once you have scrolled down all the way to the bottom, scrolling is smooth after that.
iOS WebView apparently caches elements for hardware acceleration in some buffer as you are scrolling. Once it has seen the entire list, it is cached and then it is smooth.
The CSS moves the caching from as-you-go to up-front. You take a hit at page rendering, but hopefully the user does not notice. It helps if you also deal with click delay or other up-front issues. When you start scrolling, it is smooth from the start because the caching is already done.
Leave a comment on watusiware's reply
iOS didn't seem to cache anything in my form :-)
Without the translate I could drag my finger once across the screen and about half a second later the scrolling started and the page jumped down the approximate scroll distance.
The "jump"-scrolling itself seemed smooth, but I did not find out where the lag was coming from - can't be click delay & I did as per your suggestion and set hover/active/up classes to the same CSS. I tried to listen to touchstart (fired immediately) and touchend (firing after the delayed scroll), but that did really lead me anywhere.
Without the translate I could drag my finger once across the screen and about half a second later the scrolling started and the page jumped down the approximate scroll distance.
The "jump"-scrolling itself seemed smooth, but I did not find out where the lag was coming from - can't be click delay & I did as per your suggestion and set hover/active/up classes to the same CSS. I tried to listen to touchstart (fired immediately) and touchend (firing after the delayed scroll), but that did really lead me anywhere.
Leave a comment on frequent's reply
I would start with something like .ui-listview, .ui-listview * or even the Draconian .ui-page * and see if that works. Then work-back from there and see what you can eliminate from the selector if you see a big up-front cost to this.
My long lists are all pretty conventional listviews with text and icons. Each item is 4-5 lines, you see something like 4-5 items on the page at a time, and the lists are 30 items. It's FourSquare places data.
Forms might act quite differently.
My long lists are all pretty conventional listviews with text and icons. Each item is 4-5 lines, you see something like 4-5 items on the page at a time, and the lists are 30 items. It's FourSquare places data.
Forms might act quite differently.
Leave a comment on watusiware's reply
Agree on forms. IThe form scrolls now, not perfect, but on the right track. I guess I can make it go from scoll-on-steroids to closer to regular by just adding back all box-shadows and gradients :-)
Leave a comment on frequent's reply
What I notice on iPad is the page containing the form now being rendered.... how to say ... shitty....:-)
I used to have a clean fade/slide transition to the page, now it's re-rendering (not really tiling, but close). So I guess I'll not be putting the translate on the page.
I used to have a clean fade/slide transition to the page, now it's re-rendering (not really tiling, but close). So I guess I'll not be putting the translate on the page.
Leave a comment on frequent's reply
just saying thanks for the post, very helpful.
we ended up only handling some events only if thte source was not a list item.
did the trick
Leave a comment on aviv.agra's reply
this doesn't seem to be an issue on normal lists anymore, but split view lists are terrible performance wise, even when the fixes details above are applied. It is really slow even on chrome on my macbook pro with 8gb ram...
Leave a comment on scruffian's reply
Hi ... one question.
Experiencing the problem also, I removed the anchor tags from my listviews and voila, the problem dissapeared. Replacing the anchors (because the listview became a mess), and applying the following fix however as suggested at the beginning of this article:
*.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 */
*.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 */
I was wondering what the best definitions are to use where it says "copy you styles here". I tried:
background:white;
text-shadow: none;
box-shadow: none;
-webkit-box-shadow: none;
to no avail. 2 queries:
1. Does anybody have a set of css properties that can best be used
2. Is there an approach by removing the anchors and fixing the listview mess that results of removing them. ????
Your solution worked great for me. The issue I was having was on Android Chrome, multiple cells were being left in a selected/highlighted state as the user scrolled. Less of a performance issue, Chrome was making no attempt to reset the cells and just leaving them that way. By implementing your solution, it solved the issue. Also it greatly increased the performance of scrolling listview on iPhone. So big thanks for this.
Edit: Oops, I thought it worked great but now I have an issue with it. I use multiple themes in my web application. I applied your solution to the a-theme and it worked fine for the lists that use the a-theme, but for some reason a list that uses the c-theme will not work right. It still is showing the hover colors on c-theme list and I have no idea why it would be working differently for that theme.
Leave a comment on steviewright's reply
Change topic type
Link this topic
Provide the permalink of a topic that is related to this topic
Reply to watusiware's discussion
{"z26229671":[14737000004786203],"z5569958":[14737000002986203],"z4523444":[14737000002899484,14737000002899597],"z296712":[14737000003265100],"z18881637":[14737000003279733,14737000003279679],"z24628207":[14737000004471167],"z600308":[14737000002899486,14737000002906205,14737000003331667,14737000003332659,14737000003333685,14737000003334719,14737000003360139,14737000003452849,14737000003503089],"z5620536":[14737000003677101],"z5049151":[14737000003017549,14737000003526720,14737000003526772,14737000003526780,14737000003526808,14737000003526820],"z22505777":[14737000003639638],"z3521971":[14737000003332713,14737000003463747,14737000003469195,14737000003500955,14737000003503093],"z18886952":[14737000003332125,14737000003332159,14737000003332235,14737000003332457,14737000003331687,14737000003332693,14737000003334707,14737000003334767,14737000003452859],"z19170161":[14737000003361019,14737000003361071],"z5497868":[14737000003360554],"z8646965":[14737000003248001],"z7664639":[14737000002899364,14737000002899581,14737000002910359,14737000002986233,14737000003011326,14737000003334047,14737000003334073,14737000003334361,14737000003334577,14737000003361037,14737000003467193,14737000003467211,14737000003502979,14737000003527724,14737000003527764,14737000003527772],"z7208370":[14737000002904741,14737000002906423],"z7947755":[14737000003501399,14737000003501407,14737000003501449,14737000003501465],"z8121086":[14737000002910319,14737000002910351,14737000002910353,14737000002910691]}