• iOS continues using "the trick", isn't it? Last time I checked, scrollers for native apps weren't free, but one screen dimension swipe. (Don't know if you can get the idea, sorry for the explanation).
  • Scrolling in iOS is actually pretty smooth from my experience. The only thing that doesnt work at all is flick scrolling.
  • All right, I'll call @erupnu and @IngloriousApps with another $250, rounding up to a whooping $1000. I wish I had the time to tackle this myself but I also like to see the unleashed power of the open source community in action. What are you waiting for? GO!
  • edited February 2012
    So I have to pose this question - is it all scrolling or is it just scrolling on VirtualList components? I really only have the Android browser to play around with, but here's what I'm seeing:

    This is a trivial example of a 3 panel layout in Enyo 1.0 that has a 100 item VirtualList that's, well, slow as hell in the Android browser. So yeah, I see that being an issue.

    The first tab has another VirtualList and it's also dog slow. But the second tab ("beardcast") scrolls smoothly.

    Here are the components:
    	components: [
    		{name: "getBeardcast", kind: "WebService", url: "./nitrobeard-feed.php5?beardcast=true", handleAs: "xml", onSuccess: "gotLatest", onFailure: "gotLatestFailure"},
    		{name: "MainScroller", kind: enyo.Scroller, horizontal: false, flex: 1, className: "beardcast-scroller", components: [
    			{name: "MainHolder", kind: enyo.Control}
    		{name: "StatusBar", className: "status-bar", showing: false}
    And here's how it's populated (this is a handler for a WebService component):
    	gotLatest: function (inSender, inResponse) {
    		this.InitialUpdate = true;
    		var data = inResponse.getElementsByTagName("item");
    		var i;
    		this.Stories = new Array();
    		for (i=0;i<data.length;i++) {
    			var tmp = this.xml_to_json(data[i]);
    			var tdiv = document.createElement("DIV");
    			tdiv.innerHTML = tmp.description;
    			var timg = tdiv.getElementsByTagName("IMG");
    			if (timg && timg.length>0) {
    				tmp.thumbnail = timg[0].src;
    				{kind: "BeardcastCell", url: tmp.enclosure.url, title: tmp.title, src: (tmp.thumbnail?tmp.thumbnail:"icon.png")}
    From what I've seen, it's not the scroller that's at issue in Android, it's whatever makes that scroller "virtual."

    I don't have a solution, but it certainly looks like if you can get away with not using a VirtualList you might be better off cross-platform for the time being - and to be honest you probably don't need it unless you're scrolling through hundreds of elements.
  • Okay - decided to show, not tell - but I can't delete my last comment. Sorry for the scroll!

    The app now lets you toggle between a VirtualList and a basic Scroller with a bunch of Items. There's a huge difference in Android, and I don't have an iOS device to test with. But I'm thinking that until someone finds a fix-all solution the safe bet is to avoid VirtualList whenever possible.
  • It's 'flick scrolling' that's the problem across all the platforms...
  • edited February 2012
    Hmm, even basic scrolling (not flick) and without VirtualList is extremely jerky on an Android 2.3 phone (HTC Desirce). It's ok on Android 3.2 and 4.0.
  • Flick scrolling halts in Enyo unless you are at the top or bottom of a list, throwing a warning about "Ignoring a drag while waiting for WebCore to catch up" at least on CM7 and CM9 on TouchPad. I've heard that other devices are less problematic, but still problematic.

    VirtualRepeaters scroll just fine (within reason), so long as you don't remove your finger from the scroller, as soon as you do, it throws that warning.

  • As I tried to say back in the day, iOS browser doesn't make true flick, but snap scrolling to the next piece of window (probably because of this slugginess), and nobody seems to complain about it.

    Maybe this is the path to follow?
  • edited February 2012
    I have successfully been able to integrate iScroll 4 into my Enyo projects but not as a kind and it has some quirks still. For example a click event fires where and whenever you lift your finger when scrolling. The implementation is pretty straight forward just provide a 2 div container (since iScroll will only scroll the first child) over the area you want scrolled and initialize it in the render function. Also the main container must have a non 0 height.
      name: "LongScroller",
      kind: enyo.VFlexBox,
      flex: 1,
      components: [
        {kind: "Button", name:"refresh", caption: "Refresh", onclick: "clickme"},
        {name: "mainscroller", flex: 1, style: "height: 800px;", components: [
          {name: "lister"}
      create: function() {
        var numItems = 250;
        for (i=0; i<numItems; i++){
          if (i%2==0){
    	var row = "margin-left: 5px; padding: 4px; background-color: grey;";
            var row = "margin-left: 0px; padding: 4px;";
          this.$.lister.createComponent({owner:this, content: "This is item #" + i, style: row});
      rendered: function(){
        this.myScroll = new iScroll(this.$;
  • edited February 2012
    If the scrolling is smooth with iScroll, and the only issue @syntactix is having is the click event firing, then why not ignore the click event?

    In theory, couldn't we preventDefault() on the click event on the entire scroller, then, on the individual item listen for, say, a touchstart event and then a touchend event following it?

    I'm completely inventing this as I type, but why not, on the touchstart on the list item set a variable like this.itemTouch=true and set a timeout to clear that variable to false, then on the touchend event, if this.itemTouch is truthy, fire what would normally be the onclick handler.

    If the setTimeout on the touchstart handler is adjusted properly, it should detect a reasonable "click" type event.

    Again, this is all theorizing on my part, but it could be a solution (albeit a hacky one) to keep the click event from firing when scrolling.

    itemTouchStartHandler: function(inSender,inEvent){
    itemTouchEndHandler: function(inSender,inEvent){
      //insert code to fire when an item is clicked.
    Now, I'm not sure if the row index is sent back with the touchstart event, but this can be fixed by your getItem function by setting a custom "itemIndex" property on the kind to the index of your data array. Then, just reference inSender.itemIndex. Obviously, needs tweaking, but still.
  • edited February 2012
    Also, why does my code look like garbage when compared to Syntactix's? Nevermind... read the announcement
  • had a similar thought, @zhephree. Here's an enyo kind that encapsulates iScroll and doesn't propagate clicks during scroll. I've only tested in Chrome under limited conditions but it's hopefully another step toward a solution.
  • Ooh, nice. I'm not by my computer. Someone should try this on ios and report the findings :)
  • I guess the question on top of that, is how well does the scrolling work? From what I saw in chrome, it was pretty glitchy even when used exactly as intended. I hadn't quite figured out how to make it behave properly, and especially had problems in all of my situations, where the lists are regularly re-rendered.

    I also had to mod the iScroll source just to get it to even function in Chrome 17, with Enyo.

    (also, i tried to post this message from my TouchPad, but was unable to.. when I came back to it from PC, it brought up the incomplete message, and let me send it)
  • I'm trying ryan's out, and all i'm getting is a scrollbar that moves, no scrolling. Switching useTransform to true gets it moving sometimes on Chrome 17, but not reliably. Doesn't move at all on webOS 3 no matter what I do.
  • i only had a chance to try it on my pre2 and it scrolls but not very well. If someone wants to try it on their android (or bb or symbian I suppose) device, you can get it here. I don't have an iOS account so that version isn't available.

    I might try to expose some of the iScroll options in the UI so you can experiment with each on various devices.
  • No go in CM7 on TouchPad, for sure. Barely moves at all.
  • If no one solves this by the end of this weekend, my $500 offer is off the table :)
  • You might want to request that the solution be open sourced and freely licensed -- rather than collect $1000 and have it closed sourced and commercially licensed.
  • Just noting that the scrolling problem is really hard. Even the best programmers out there have tried with limited success. See Joe Hewitt's Scrollability library for another attempt, although his blog post on CSS key-frame animation has some interesting ideas, although I'm guessing the variability of webkit implementations is going to stymie things.
  • As mostly webOS tablet developers we really are punishing the DOM compared to what everyone else does, too. Note that Scrollability there seems to work really well at a first glance, but the lists that it's moving are exceptionally simple compared to stuff that we move around with ease on a TouchPad.
  • (Part of) The issue with iScroll vs the ScrollingList implementation is the absence of optimizations of list rendering. In my example, I was rendering 1000 list items which is s lot to handle but even 200 was too tough for smooth scrolling. VirtualList only renders the currently visible page plus a little on each side. Assuming iScoll's scrolling logic is more performant across platforms than Enyo's, we'll have to either adapt the optimizations to iScroll or iScroll to the optimizations.
  • @unwiredben When you say the problem is really hard, are you saying this won't be solved in enyo2?
  • You can see what enyo2 does right now -- just look in the touch folder in the source tree.

    We're working on solutions, but we don't have them yet. So far, our observations are that scrolling is just horrible on Android 2.x due to the immature WebKit version. Things are best on iOS 5 on the A5-based devices (iPad 2, iPhone 4S), and there's been improvement with Ice Cream Sandwich. However, GPU speed, CPU speed, memory architecture, and the version of WebKit all matter here.

    Our first drop of widgets will mainly be the nuts-and-bolts type controls, the buttons and checkboxes and toolbars and radio buttons that you use to make a UI. This doesn't include things like VirtualList -- we're still working on getting those implemented well for browsers other than the webOS one. The work you all are doing on the Enyo 1 code are directly impacting our own investigation here.
  • I think scrolling should really be something native implemented in the rendering engine (WebKit).
    In no way JavaScript was built to handle things like this.
  • And it should by async, so that JavaScript can do something while the engine scrolls.
  • While that could be implemented in Isis, that doesn't help for other platforms :(
  • Well, mobile browsers should at least properly implement "overflow: scroll"
  • Definitely agree that browsers should be implementing this, although it's a tough thing -- in the general case for web pages, the browser needs to know if you're scrolling the whole page or just a subarea. I know on some platforms, they use two-finger scroll for the inner areas, but that's not great except when it's the only way to get an external page to work.
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!