• Here's a rough idea i had. Could you use the "captureDomEvent" in your kind to sort off supplement scrolling?
    I've also noticed on ios5/ipad 2, scrolling isn't really slow, it's just hard for it properly decode exactly what your finger is doing. I've noticed if I sort of lightly swipe up on a list, it registers as a flick, and it scrolls as desired. But if you tap, hold, flick and release, it stutters. It's kinda hard to explain, but i feel somewhere in the enyo code, there's a combination of preventdefaults/stoppropagation that's screwing up touch events. But again, I'm no expert in these type of things, maybe I'm not even making sense...
  • In my research on the log warning message that Phonegap seems to be throwing when that happens, people found two different things that seemed to affect it .. adding/removing preventDefaults, and using the event.touch[0].pageX and event.touch[0].pageY information, rather than the event.pageX and event.pageY information. That touch array doesn't seem to be very commonly present though.

    And my understanding of exactly how to use them is pretty close to nil.
  • Since Android 2.3 seems to be the most problematic target here, I tried lists with jQuery Mobile 1.0 and Sencha Touch 2.0 Beta there.

    jQuery Mobile scrolls its (non-virtual) lists very nice. But they scroll the entire screen, meaning the fixed header and footer disappear during scrolling and reappear when stopping, so this looks like a (cheap) trick.

    Sencha Touch 2 scrolls nicely with very simple items in its (I think virtual) lists. When the items get a little more complex than one line, it slows down. They are claiming, that they have done various optimizations in 2.0 for scrolling on Android, maybe it's worth to take a look and borrow...
  • ...but not borrow directly, since Sencha's license is strict GPL unless you pay them lots of money.
  • I'm guessing this issue isn't as simple as tweaking the ScrollStrategy parameters (kFlickScalar, kFrictionEpsilon, etc)?
  • JQuery claims they have it:
    That sounds really interesting:
    The coolest part about this approach is that, unlike JS-based solutions that impose the unnatural scrolling physics across all platforms, our scrolling feels 100% native because is *is*.
    Anyone gonna try it?
  • Has anyone tried using DOM attributes and overflow:hidden like Ben suggested in the first page? Or have you guys only been looking for other code and trying to adapt that instead?
  • I'm suspicious that JQM's solution only applies to full screen scrolling with a fixed header /footer and not interior div scrolling but I haven't tried it to know. That's certainly a reasonable approach for a phone UI where it's likely you'll be only displaying a long list but probably doesn't apply to a tablet interface where the list may only be one column (e.g. the various twitter clients).

    Course, I could be completely wrong too :)
  • The overflow:hidden strategy is what you get in Enyo 1.0 when accelerated is false.
  • I modified the enyo 1.0 scroller to remove the accelerated method and override the non-accelerated method to make it modify DOM attributes instead, but @IngloriousApps tried it out and there was no/little difference. I'm pretty sure some of the third-party solutions suggested here do the same thing (and also don't solve the issue).
  • Sigh...sadly, I'm gonna have to stop working on enyo ports, since this scroller situation is basically hopeless
  • @IngloriousApps Really? I find that my apps are working well on iOS despite the lack of support for flick scrolling. Android 2.x, as others have pointed out, is a entirely different case...
  • @maklesoft Yes really. I'm not satisfied with the scrolling on the ipad (I'm not even bothering with android atm). My app depends heavily on scrolling, and I can't in good conscience release it in it's current state. ios users aren't as forgiving as webos users :)
  • Gotta ask a dumb question. I haven't fiddled with enyo2 yet, but is this scrolling issue solved in enyo2?
  • No, it's not completely solved in Enyo 2.0. This is a very hard problem.
  • jQuery Mobile 1.1.0 RC1 scrolls very fast/smooth on iPad 1 with iOS 5 and HTC Desire S with Android 2.3. Not so good, but still somewhat acceptable on Motorola Xoom with Android 3.2. This is with lists with more than a simple line of text (actually 3-4 lines of text per list item).
  • @sidamos by 'list' you mean enyo virtuallist?
  • @sidamos by 'list' you mean enyo virtuallist?
  • @unwiredben very hard != impossible right? :)
  • @enyoteam: I know you guys said you initially tested enyo(1) on ipads. What kind of tests did you guys do? Because I'd think "scrolling" would be high up in the list of tests. I know obviously, more effort was put into making things work for webos first, but was enyo actually ever meant to be cross-platform from it's initial inception?
    I don't think people would take enyo'd apps seriously if this scrolling issue is swept under the rug...unless if you're making an app with a bunch of buttons and toggle switches
  • @IngloriousApps no, I tested normal jQuery Mobile 1.1.0 lists. They do not have virtual lists...
  • I'm wondering, how does scrolling compare in the iOS/Android browser compared with PhoneGap. Could it be a PhoneGap problem?
  • @rsanchez1 For iOS 5, everything is a bit faster in Safari than in webview apps. But that is the fault of Apple. They disable the JS JIT compiler in webview apps. BTW, iOS 5 is slower than iOS 4 in this regard.

    Similar effects on some older Android versions. Rotating with CSS is very slow in webview apps on Android 3.1 and good in the browser (Motorola Xoom).
  • Hey, all - we're definitely not looking to sweep anything under the rug. As Ben has pointed out, scrolling in JavaScript apps on mobile devices is a difficult, multi-dimensional problem.

    While scrolling performance depends in large part on software components "lower in the stack" than Enyo, we recognize that it's important for us to make scrolling work as well as we possibly can, so we have been doing a lot of work on this and will continue to do so. I'm going to take the time to write up a longer forum or blog post on this topic over the next few days, so stay tuned.
  • If only the modifications you did in webOS to make Mojo scrolling fast were standard...
  • I was under the impression that Mojo scrolling was fast and efficient because a) it was used on much smaller resolution screens, and b) webOS >=2.x had built-in optimizations, much like how enyo scrolling relies on 3D acceleration and some webOS tweaks to perform (relatively) fast.

    Has anyone tested a Mojo scroller outside of a webOS smartphone?
  • Has anyone tested a Mojo scroller outside of a webOS smartphone?
    Well on the TouchPad, and scrolling there is pretty okay too.
  • On the TouchPad, Mojo scrolling uses all CPU, calls to SQL take forever.
  • The fact that the TouchPad must emulate older apps at all suggests that Mojo must have had some hardware optimisations or something in the early versions of webOS. I'd bet that they perform equally as bad as the enyo scrollers do on Android etc.
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!