• If you look at the first page of this getting-way-too-long thread, I note about the special CSS style added to webOS to support Mojo scrollers and how they operated differently from the Enyo ones.
  • Lol. I didn't expect this to get dragged on like this
  • @omastudios
    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.
    I don't think the TouchPad emulates Mojo apps. The emulation window is just for apps that depend on the back gesture, as the TouchPad has no gesture area, and you can simply disable it by an entry in appinfo.json.
    My Mojo apps have pretty fluid scrolling on the TouchPad in fullscreen.
  • @pcworld As Ben said, Mojo uses custom CSS rules that trigger platform specific behaviour, so while it works on the TouchPad, the point about it not functioning correctly on other platforms still stands
  • anyone notice this one?

    Not sure if that could be adapted or not, it says it has some iOS support.
  • hmm. wish i could edit longer than 15 minutes past :D that flexcroll is not freely available, it's free for non-commercial, and doesn't come with legible source unless you pay.
  • It looks like for Enyo 1.0 the flick event was a custom event for WebKit on the Touchpad only? In Gestures.js in Enyo 2.0 I noticed that flicks were detected and/or emulated based on the drag velocity. I got much better results on the iPad 2 by changing the following functions in the // base/scroller/ScrollStrategy.js section of enyo-build.js.

    startDrag: function(a) { this.dragT0 = new Date().getTime(); this.dragging = !0, = a.pageY, = = this.y, = a.pageX, this.px = this.ux = this.x; }, dragFinish: function() { this.dragging = !1; var dragT1 = new Date().getTime() - this.dragT0; var vx = (this.x - this.px) / dragT1 * 1000; var vy = (this.y - / dragT1 * 1000; var v = Math.sqrt(vx*vx + vy*vy); var minFlick = 600; if (v > minFlick) { this.flick({xVel:vx, yVel:vy}); } },
    The technique was borrowed from Enyo 2.0 and is not fully tested or guaranteed to work for all Scrollers. It works well for me in a VirtualList and a Scroller inside a Carousel.
  • Well, I'll be damned! It works. I could kiss you @rustyapps
    (tested on ipad2/ios5)
  • i'll check it on Android tonight and hopefully my arriving PlayBook tomorrow.
  • Testing on Kindle Fire (VirtualRepeater of about 20 basic items) and seems to be better, but not perfect (compared to TouchPad). It feels kind of sluggish still, but scrolls better than before. Messing around a little:

    Changing the lines :
    var vx = (this.x - this.px) / dragT1 * 1000;
    var vy = (this.y - / dragT1 * 1000;
    var vx = (this.x - this.px) / dragT1 * 3000;
    var vy = (this.y - / dragT1 * 3000;
    seemed to make things appear a little smoother. Someone with a little more knowledge might be able to explain what that does, but my guess is raising that multiplier will help on slower devices, or maybe just Android in general.

    Flick events are still hit or miss, mainly shorter, quick flicks don't get picked up. I believe there is a lag from the start of the drag to the drag actually being picked up, so short flicks don't register. Faster devices might not have this issue.

    Thanks @rustyapps! Awesome work!
  • @machiapps, multiplying by 3000 instead of 1000 has the effect of increasing the velocity by a factor of 3. i.e. it will scroll faster.

    You might want to add a console.log("startDrag here") to the startDrag function to test if the short flicks are registered at all.
  • edited March 2012
    I made a few changes to improve performance on the iPad 2. As @machiapps did I increased the velocity, but by a factor of 1.2, which looks good to me on the iPad. I also fixed it so it would flick correctly after scrolling up and down repeatedly without lifting your finger. It now restarts the flick detection with each direction change. I also added a time limit of 300ms, after which a drag will not be detected as a flick.

    (note that dragDrop() is included in the code below but I didn't edit it)

    functions edited in enyo-build.js:
    startDrag: function(a) {
    this.dragT0 = new Date().getTime();
    this.flickx = this.x, this.flicky = this.y;
    this.dragging = !0, = a.pageY, = = this.y, = a.pageX, this.px = this.ux = this.x;
    drag: function(a) {
    if (this.dragging) {
    var b = this.vertical ? a.pageY - : 0; = b +, = this.boundaryDamping(, this.topBoundary, this.bottomBoundary, this.kDragDamping);
    var c = this.horizontal ? a.pageX - : 0;
    var currentsign = 0;
        currentsign = (((b-this.lastb) < 0) ? -1 : 1);
        currentsign = (((c-this.lastc) < 0) ? -1 : 1);
    if( currentsign != this.lastsign  ){
        this.dragT0 = new Date().getTime();
        this.flickx = this.x, this.flicky = this.y;
    this.lastsign = currentsign;
    this.lastc = c;
    this.lastb = b;
    return this.ux = c + this.px, this.ux = this.boundaryDamping(this.ux, this.leftBoundary, this.rightBoundary, this.kDragDamping), this.start(), !0;
    dragDrop: function(a) {
    if (this.dragging && !window.PalmSystem) {
    var b = .5;
    this.y =, this.y0 = this.y - (this.y - this.y0) * b, this.x = this.ux, this.x0 = this.x - (this.x - this.x0) * b;
    this.dragging = !1;
    dragFinish: function() {
    this.dragging = !1;
    var dragT1 = new Date().getTime() - this.dragT0;
    var vx = (this.x - this.flickx) / dragT1 * 1200;
    var vy = (this.y - this.flicky) / dragT1 * 1200;
    var v = Math.sqrt(vx*vx + vy*vy);
    if (v > 600 && dragT1 < 300) {
        this.flick({xVel:vx, yVel:vy});
  • How well or bad does this perform on the TouchPad or webOS phones?
  • edited March 2012
    I've taken the freedom of pulling this on the repository. Seems a great catch, guys!
  • I'm looking at the pull request now. The patch needs a little cleanup to better match the original source (variable names, etc), and I need to know how it affects things on webOS.
  • I'm also very interested in how it affects performance on webOS. IF it improves performance on phones, great! But if it lowers performance on the Touchpad, not so great.

    Just in case you guys need another source of inspiration, this popped up in my rss:

    Looks like these guys are pretty confident they figured out scrolling. One of their improvements is:

    "optimizing scrolling frame rates"

    And Sencha Touch 2 is advertised for iOS and Android.
  • That looks promising, particularly the infographic:


    What do Sencha recommend for deploying on Android/iOS? PhoneGap or something else?
  • Sencha have their own packaging, at least for iOS. But you can use PhoneGap of course. But Sencha "feels" a little bloated. It's practically ExtJS for mobile. Also, as Ben already mentioned, we can't use part of their code because of the license.
  • edited March 2012
    What's wrong with their commercial software license?

    From what I can see, it doesn't permit direct integration into enyo, but is good on a per app/developer basis (so still useful).

    EDIT: better overview of the license here:
  • Nothing prevents you, as a developer, from using Sencha Touch in your app, even combined with Enyo. However, we can't integrate changes based on their code back into our framework for everyone to use.
  • BTW, as I already said, Sencha Touch 2.0 scrolling on Android 2.3 is fast with minimalistic rows only. At least that's what I saw during a short test.
  • edited March 2012
    Can't test this Enyo changes on the iPad, but still does not work well with VirtualList on Android 4.0 (TouchPad). Also, it still happens, that it scrolls backwards after a few flicks.
  • *sigh* I have kinda given up on Android with Enyo 1. It is much better on iOS though.
  • edited March 2012
    @sidamos In it's current status, I don't think testing against CM9 on the touchpad gives you an idea at all about performance.
  • @rafa_bernad hmm, you mean because it's alpha? At least jQuery Mobile scrolls nice on the TouchPad. BTW, I have also done tests with Android 2.3 on an HTC Desire S.
  • @sidamos Yeah, that. And because I don't feel any of the animations smooth in the touchpad.
  • edited March 2012

    That's almost completely amazing. It scrolls very, very nicely on the PlayBook. However, the next touch after is almost always counted as a click, and doesn't trigger a scroll at all. Any chance you have it in a readable form in the source, rather than as changes to the build file? I'm hoping it's an easy fix. :)

    Also, dragging a scroller around for a little while, stopping, and then releasing your finger registers as a click. Need to defeat whatever mechanism starts the click detection, when we detect a scroll instead.
  • edited March 2012
    OK, nevermind on all that -- the extra clicks are local to PlayBook, and the extra stoppages were from a different change I had made to my Enyo there.
  • @ekdikeo @rustyapps Really? I didnt see any difference on the PlayBook at all. At least not for VirtualLists.
  • edited March 2012
    The smoothness with which it moves my VirtualRepeaters on Android CM7 and on PlayBook 2.0 is -amazing-. It's still a little laggy on Android, but then.. so is everything on Android. I vote @rustyapps for Pres.
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!