Faster Scrolling on Touch Devices

DataJog

I have found an alternative to the Scroller kind in Enyo 1.0. It is working great in Android, probably iOS too.

Add GloveBox.js to your project and depends.js file.

Then add the snappy GloveBoxScroller kind:

enyo.kind({
	name: "GloveBoxScroller",
	kind: "Control",
	create: function() {
		this.inherited(arguments);
	},
	rendered: function() {
		this.inherited(arguments);
		var gloveBox = new GloveBox(this.parent.id);	
	}
});

Replace any Scoller kind with GloveBoxScroller and enjoy fast smooth scrolling!

This is just a start. There's lot to do but it will get us going.

Bug: Keeping the scrolling within the parent element!

pcworld

Wow, thanks!
Does this also make scrolling faster on webOS phones?

DataJog

Does this also make scrolling faster on webOS phones?

No - It does not work at all on webOS phones.

DataJog

Try this sample on any touch device:

http://scrolltest.datajog.com

It does work in the webOS phone browser! It does not work as an app.

sidamos

Any chance this could enhance VirtualList as well?

DataJog

I don't see why not... Would take some refactoring. Not sure of the time benefit vs enyo 2.0 gui elements about to come out.

rsanchez1

You could just take the source for the VirtualList and its components and replace them with custom kinds, until you replace the scroller in the VirtualList with GloveBoxScroller.

unwiredben

The problem with keeping the scrolling within the parent element seems to be pretty big, especially for a lot of the applications where enyo.Scroller was used. Any ideas why that's happening?

unwiredben

From looking in Glovebox, it looks like the key bit of scrolling code is

_updateTransform:function()
{
    this.element.style.webkitTransform = "translate3d("+this._x+"px,"+this._y+
        "px,0px) scale3D("+this.scale+","+this.scale+",1.0)";
},

where it's using a 3D translation while also applying a scaling factor.

The accelerated scroller in Enyo uses the same mechanism, but without the scale3D transform, see TransformScroller.js.

So, either the scale transform parameter is really important, or there's other magic here. From the looks of the code, this.scale doesn't seem to matter much if you're not doing pinch-zoom, so I'm guessing the second.

One thing I notice is that it uses the webkit-transition style to set different transitions. This means that scrolling isn't just happening when the style changes, but happens under webkit control, so instead of setting the style to change the scroll to 20, then 30, then 40, etc, they just set the scroll to 40 and let the transition logic handle the intermediate steps. This is something that Enyo code doesn't do, making the Enyo code a bit more JS runtime heavy.

erupnu

Ben,

I tried adding the scale3D to my Enyo source and saw no real improvement on my iPod. Looks like it's not the magic bullet.

unwiredben

No, I'm thinking the real improvement is using the transitions to do the 3D transform scrolling outside of JS control.

DataJog

Ben - you are correct - I'm cooking up a version using webkit-transition and it's much better. I'm trying to make a new ScrollStrategy kind. I also found modifying webkitRequestAnimationFrame has helped.

When I have more, I'll post it.
Scott