My name is Dimo Dimov and I am the support lead at Kendo UI.
Let me first express my regret about the disappointment this thread has caused. I agree that exchanging multiple messages to clarify a test case and the reproduction steps can lead to justified frustration, especially if you are working on a tight schedule to release an application. That includes the case when two similar, but also different scenarios are perceived as one. Please accept my apologies.
Let me provide an overview of the situation and the next steps.
When using local data operations, the Kendo UI DataSource stores the data items in their initial non-manipulated state (i.e. non-sorted, non-filtered, non-grouped state). In order to display sorted or filtered data, the Grid executes DataSource API methods. The DataSource instance performs the desired operations in-memory and returns the expected data items. The specific "view" of the data items in the current sorted or filtered state is not stored. As a result, when paging or scrolling virtually, the same sorting and filtering operations are performed again on the whole dataset. This is a fundamental design decision that has its pros and cons, but ultimately, the way it works now saves memory. Indeed, the speed of client-side data operations will depend on the device and when there is a huge number of items (over tens of thousands), a noticeable lag may occur during virtual scrolling.
To mitigate the issue described above, the inPlaceSort property was introduced in 2017.3.913. It makes the DataSource store data items in their sorted state, which improves client-side performance during client-side paging and virtual scrolling. Testing with earlier Kendo UI versions, which do not feature inPlaceSort, will result in slow virtual scrolling indeed, because the DataSource will sort all data items repetitively, every time when new items should be rendered.
In this specific case, we were not able to observe the severe lagging shown in your videos initially, but it turns out noticable lagging does occur when we scroll near the bottom of the Grid. In any case, we admit the client-side performance will depend on the Grid configuration, the browser and the device power. It is also worth pointing out that there is no "inPlaceFilter" feature. So, using client-side filtering together with virtual scrolling and a huge number of data items will still impose a performance penalty during scrolling.
If sorting, filtering and virtual scrolling are all required features in your use case scenario, and the expected number of data items is large, then my recommendation is to resort to remote data for the best performance. I can confirm that virtualization with huge large amounts of local data is a rare use case, hence the currently assigned priority of the logged sorting bug
. Nevertheless, I recognize the importance of the fix to you. I discussed it with the dev team and they will research if there is a quick way to fix it, so that we squeeze the implementation in our short-term to-do list. I expect this research to take place in the following days and will update you promptly as soon as I can.
Let me know if you need more information in the meantime. Once again, I sincerely apologize that we started off on the wrong foot in this support interaction.