Thank you for reporting this bug. We will make it our priority to review this report.
Very hard to not hit bug with grid virtual scrolling if getting data using AJAX proxy
Using 4.0.0 it's very hard to not hit bugs with grid virtual scrolling if getting data using AJAX proxy.
All example (one only exist) of Sencha is using memory proxy.
Our scenario is to use an AJAX proxy to load/reload/changeQueryCriteria of the store to load all the data and still get a fast grid to show up.
With only interaction with the store depending of the parameters of page size, limit, and method called, we can get different UI behavior of the Grid ! Store changing UI.. instead of just the data.
We can get those different behaviors:
- fast grid where only the visible row rendered
- all row rendered even the not visible row, so very slow initialization
- only row visible rendered, but when moving the scroller nothing change in the view beside the scroller!
It would have been nice that the statement rom Ed that by default the grid is always using virtual scrolling was reality instead of a dream.
An easy way to see the design problem that cause this mess, is to change the store pageSize of Sencha example http://dev.sencha.com/deploy/ext-4.0...ffer-grid.html
The default value of pageSize in the store in the example is 50, and it works fine with it.
Then when we change the value of pageSize from 50 to 4000 it dramatically slowdown the speed of scrolling! Keep in mind that this store is in memory with buffered = true, and purgePageCount = 0, and pageSize is a only a store option.
PageSize is about how to call backend to retrieve piece of data, and we of course don't call backend when we scroll. So unrelated settings has an effect on an unrelated concept -> the way the lazy rendering of row happens.
An other test, if you change the pageSize from 50 to 5, and then match the same with
store.guaranteeRange(0, 4) you get this behavior, you see only 5 row in the grid and no more vertical scroller, but the grid store still has 5000 rows, so what happened? We didn't touch any view settings, but the view decided to slow only a part of the store data, strange.
An this go on, and on. It's hard to make sense of this.
I think in Sencha example after store.cacheRecords(records) we should not need to "wake_up" the store that it has new data, so we should not need to call store.guaranteeRange(0, 49). If we need an extra call because the store want to do lazy wake-up of its view, the call should be something like store.changed() without any extra parameter.