2.1 - HUGE performance issue with DataView scrolling and painted browser events

[intellix]

ST: 2.1.0
Browsers/OS: Everything (even chrome you can see it jerking a little)
Component: DataView

Not sure where to put this but this is what I've come across whilst debugging huge performance issues with my DataView pages that contain many components.

Using Android and actually iOS as well I noticed that one of my pages was extremely heavy and basically unusable (despite looking VERY simple). Android it pretty much froze.

If you go into Chrome Inspector > Timeline > Record
Start to drag up and down the page, you'll notice that there are a hell of a lot of Recalculate style and when you look into the cause, this is basically the StackTrace which is causing there to be so many Style Invalidations

Before: https://www.dropbox.com/s/sde7jev4fw...yle-events.png

Ext.dom.Element.addMembers.removeCls     @    sencha-touch-all-debug.js:13139
Ext.dom.Element.addMembers.replaceCls     @    sencha-touch-all-debug.js:13156
Ext.define.updateCls     @    sencha-touch-all-debug.js:22522
setter     @    sencha-touch-all-debug.js:5428
Ext.define.removeCls     @    sencha-touch-all-debug.js:22430
Ext.define.onItemTouchMove     @    sencha-touch-all-debug.js:49029
Ext.define.doFire     @    sencha-touch-all-debug.js:14752
Ext.define.fire     @    sencha-touch-all-debug.js:14679
Ext.define.doDispatchEvent     @    sencha-touch-all-debug.js:15173
Ext.define.dispatchEvent     @    sencha-touch-all-debug.js:15154
Ext.define.doFireEvent     @    sencha-touch-all-debug.js:15452
Ext.define.fireEvent     @    sencha-touch-all-debug.js:15410
Ext.define.onItemTouchMove     @    sencha-touch-all-debug.js:47380
Ext.define.doFire     @    sencha-touch-all-debug.js:14752
Ext.define.fire     @    sencha-touch-all-debug.js:14679
Ext.define.doDispatchEvent     @    sencha-touch-all-debug.js:15173
Ext.define.dispatch     @    sencha-touch-all-debug.js:60449
Base.implement.callParent     @    sencha-touch-all-debug.js:4596
Ext.define.dispatch     @    sencha-touch-all-debug.js:73221
Ext.define.doPublish     @    sencha-touch-all-debug.js:73314
Ext.define.publish     @    sencha-touch-all-debug.js:73228
Base.implement.callParent     @    sencha-touch-all-debug.js:4596
Ext.define.publish     @    sencha-touch-all-debug.js:74256
Ext.define.onTouchMove     @    sencha-touch-all-debug.js:74418
override.processEvent     @    sencha-touch-all-debug.js:74529
Ext.define.onEvent     @    sencha-touch-all-debug.js:74133
Base.implement.callOverridden     @    sencha-touch-all-debug.js:4714
override.onEvent     @    sencha-touch-all-debug.js:74525
(anonymous function)     @    sencha-touch-all-debug.js:3169

So it seems that everytime you drag your view up and down, it's removing the classes within your DataView and readding them here:

onItemTouchMove: function(container, target, index, e) {
        var me = this,
            store = me.getStore(),
            record = store && store.getAt(index);


        if (me.hasOwnProperty('pressedTimeout')) {
            clearTimeout(me.pressedTimeout);
            delete me.pressedTimeout;
        }


        if (record && target) {
            // Everytime you move the view, it removes the pressedCls but it was never added yet
            target.removeCls(me.getPressedCls());
        }
        me.fireEvent('itemtouchmove', me, index, target, record, e);
    },

My workaround that makes it feel absolutely rapid (you may have something better, if so provide):

// Inside touch/src/dom/Element.style.js

replaceCls: function(oldName, newName, prefix, suffix) {
        // If nothing has changed, why are we removing all classes and readding them causing a repaint?
        if (Ext.isArray(oldName) && Ext.isArray(newName) && oldName.join() === newName.join()) {
            return;
        }
        return this.removeCls(oldName, prefix, suffix).addCls(newName, prefix, suffix);
    },

After: https://www.dropbox.com/s/763dkzs4e4...ts-after.png?m

Sorry I didn't fill out a form but think half of the data on there is so redundant

[mitchellsimoens]

We can take a look at this. I have opened a bug in our bug tracker.

[jweber]

I tried this on a ST2.1 DataView, in a PhoneGap app, on a Galaxy Nexus running Android 4.2.1. It didn't seem to have a noticeable effect. Either way, there was a slight lag before it started scrolling, but after that, scrolling speed was reasonable....slower than on an iPhone or on Chrome for Android, but faster than with ST2.0.

But it makes sense, and I'm all for it if it helps in certain situations.

[intellix]

I think it depends on how much are in your dataviews. I have quite a large DOM because my DataViews are heavily nested looping through all of the data and printing it out.

I basically have:

Region > Groups > EventDays > Events > Selections.

It made a HUGE difference on here: http://m.youwin.com/#sport-region/football,england

It was basically unusable in Android and slow/choppy in iOS. Even noticeably annoying on the iPad

[Bunchofstring]

Thanks for sharing. This gives me hope for ST2.1

Your site scrolls nicely on my dual-core Android phone in Mobile Chrome, but if I flick the page up and flick again before the momentum scroll stops, it accelerates a lot and pops right to the bottom. In the default browser, it won't scroll at all.

[intellix]

Status is currently set to: Success! Looks like we've fixed this one. According to our records the fix was applied for TOUCH-3801 in Sprint 28.

Is there any additional information around what Sprint 28 is? Perhaps when it might get released or if it's in the nightly code. Sprint 28 could mean 2014 for all I know :P
Would be cool if the sticky thread in this forum explained something about the statuses assigned.

[intellix]

In regards to the above post, I also don't see it in any of the releases since this was declared "fixed". I've got a feeling it's being held back so 2.2 can be declared as having many performance improvements. Bumping this as the above fix will help improve performance for so many apps.

[cyee]

I've measured a lot of performance metrics for scrolling in 2.0.1.1, 2.1.0, 2.1.1, and 2.2.0-alpha

I have seen the biggest delta improvement in 2.1.1 -> 2.2.0-alpha, so I suspect you're right.