Closed jblas closed 11 years ago
If there's anything I can do to help push forward this - tests, example pages, whatever - please let me know. I originally thought the sluggishness was caused by the button down-like event since hacking that away in the core file improved things a bit.
I looked at your 1.1 milestone feature set and believe that from a user experience point of view, scrolling speed ( especially with lists ) is critical. Now that I've released my jQM based project, I will focus my attention on helping out with scrolling; fixed positioning and tablet support ( these all have to land with the completion of my next jQM project ).
On some android devices (I'm working with the HTC G2), small scroll gestures are not registered when you are at the very top (with address bar showing), or at the very bottom of the page. You have to drag your finger across a large section of the screen in order to scroll. Very frustrating user experience.
Other reportings of this behavior can be found here: Issue #142
Small scroll gestures work just fine when scrolling on any other part of the page. (even when only a couple pixels from the address bar are hidden)
You can see this behavior on any jquery mobile site. I've confirmed the behavior in rc1 and 1.0 final.
To fix the behavior, you have to comment out the touch event registration in jquery mobile's setup function:
// $document.bind( "touchstart", handleTouchStart )
// .bind( "touchend", handleTouchEnd )
//
// // On touch platforms, touching the screen and then dragging your finger
// // causes the window content to scroll after some distance threshold is
// // exceeded. On these platforms, a scroll prevents a click event from being
// // dispatched, and on some platforms, even the touchend is suppressed. To
// // mimic the suppression of the click event, we need to watch for a scroll
// // event. Unfortunately, some platforms like iOS don't dispatch scroll
// // events until AFTER the user lifts their finger (touchend). This means
// // we need to watch both scroll and touchmove events to figure out whether
// // or not a scroll happenens before the touchend event is fired.
//
// .bind( "touchmove", handleTouchMove )
// .bind( "scroll", handleScroll );
Note: the scroll binding does not cause the issue, but any touch related binding does.
This is not due to any weird jquerymobile code executing in the handlers.
Simply adding this code to the page will cause the behavior:
$document.bind("touchstart", function(event){})
Unbinding does not rectify the issue. eg doing this still caused the issue to occur:
.bind("touchstart", myFunc).unbind("touchstart", myFunc)
So it seems to be a quirk with some versions of the Android Browser. (I don't get this behavior on my Samsung Galaxy Tablet)
I'm not sure of the ramifications of removing the event binding from jquery mobile, but it'd be super cool if the jquery mobile team would detect problematic browsers, and not perform the binding. That is what my team will have to do for now...
No one has complained about this specific issue I described in ios.
On several Android devices, we have noticed that overuse of css3 can cause jittery/stuttering/poor scrolling. Text shadows and gradients seem to perform well, while drop shadows and rounded corners do not.
When we are talking about scroll, does it include the experimental scrollview?
@ssssssssssss
For this bug it was specifically about 'native' scrolling. If you have issues with the scrollview, please file as a separate issue. Thanks!
Hi, I noticed that if I move the <ul> list outside of the "content" div, scrolling becomes Much Faster!
Tested on Android ICS 4 + jQuery Mobile v1.0 + PhoneGap. http://ipim.me
Is there any workaround for this? Performance is really horrible on lists with more than 30 items.
Ok, there are some interesting workarounds here: http://forum.jquery.com/topic/why-jqm-touchscreen-list-scrolling-performance-stinks-and-what-to-do-about-it
I posted performance issues I'm experiencing on long form pages in another thread (https://github.com/jquery/jquery-mobile/issues/2853).
I was having a really laggy experience with scrolling a list (of thumbnails, but the error was persistent no matter wrapper (ul, div) or content (image, anchors, text).
After trying to figure out the source of the lagging i found that removing the <div data-role='content'> </div>
and just having the <ul></ul>
as main content made solved the issue completely. I use fixed footer and header like usual. Works great.
There are a lot of pieces to this puzzle. I found that registering event handlers for swipeleft and swiperight caused some serious scrolling issues on ICS and JellyBean when leaving the $.event.special.swipe.scrollSupressionThreshold at the default value of 30. I've commented those event handlers out for now, but in my testing I noticed that overriding and setting $.event.special.swipe.scrollSupressionThreshold = 100 seemed to remedy the issue (although, 100 may be too much and may cause other issues).
@antonysastre confirmed that removing the <div data-role='content'> </div> results in a significantly improved experience that i expect identical to the smooth scrolling of an html page in safari.
Hi all - Picking this back up. We've made two changes recently that help with lists. THe biggest was disabling transitions once you've scroll down more than a few screenfuls because the CSS transitions on long pages were adding seconds to delays. We also upped the scroll suppression threshold a bit.
Just curious how latest/1.2 beta is looking and is problems mainly occurs when you bind additional events like swipe to a listview so we can focus this in.
Anyone want to chime in here? Is listview scrolling still an issue?
IMHO, scrolling at least on iOS 6 is not an issue anymore. Filtering, though, is.
@toddparker I'm going to close this no response in 2 months except for @jeez saying not a problem. @jeez as far as filtering lists goes we are going to be turning the list view filter into its own extension widget for 1.4 and will look at this then.
@arschmitz It's good to know that it will become its own extension widget, but I believe the issue described at https://github.com/jquery/jquery-mobile/issues/5278 and https://github.com/jquery/jquery-mobile/issues/5328 might not be related to that and has become a real blocker for listview and iOS.
Removing
Folks have been complaining that our scrolling on iOS and other touch-based platforms is slow. Especially on listview pages.
After poking around, it looks like the slow down is caused by the framework registering touch event handlers on the document.
Simply doing this:
is enough to slow down scrolling performance in a long document with static markup and no other JS. We need to figure out if we can re-work our event handling so that we don't have to listen for touch events at the document level.