Telerik blogs
As promised, I am following up with the second part of the work we have done on RadGridView during the past release.

If you have read the first part, you would remember that our goal was to provide a stable, fast and usable GridView product which has to live up to Telerik’s high standards. In  Re-engineering RadGridView for WinForms (part I) I talked about:
  • Improvements to the UI and element painting in the Telerik Presentation Framework (TPF), which raised RadGridView’s painting speed with some 30-60%, depending on the scenario the grid is used in; 
  • Performance improvements in the data layer, which had an astonishing result. RadGridView loaded 300,000 rows of data in half a second, and grouped them in another 300ms!

Today I will cover the two remaining topics that were left out from Part I:

Performance improvements in the Data <--> UI communication

In the course of the re-factoring process we redesigned how data <--> UI communication. The idea was to reduce the middle layer and entirely eliminated its performance cost.

By extracting some common APIs into new interfaces, the data layer and UI layer presently live in complete symbiosis, communicating in the most efficient way. The Data Layer takes care of creating and initializing the logical objects that the UI layer uses to spread over its visuals. We use lazy instantiation where possible to ensure optimal swiftness in scenarios demanding both small and large amounts of data are to be visualized. For example, the grouping and aggregation objects are calculated at the time just prior to data being displayed on the screen. All operations like updating, deleting, and inserting new records of data have minimum impact over performance, especially in cases when the grid is grouped and sorted.

Stability and simpler API

We have gathered lots of information from our customers on how we can improve RadGridView in a way that it incorporates both powerful and friendly API.

One of the most delicate areas concerned grid rows and columns. We received numerous reports describing troubles accessing RadGridView rows with the need to retrieve/store values of grid cells. We found it curious that most developers feel more comfortable editing data using the API rather than through their app’s data-layer, but nevertheless this is the approach we decided to follow. After all, things should be easier for our customer, not for us :)

The main trouble was that when first designing RadGridView’s APIs we thought that the Rows property should resemble the visual representation of the data. The hierarchically structured Rows consisted of both calculated rows (like group headers), and rows that contain the actual data. Well, many of our customers found this model very difficult to work with, so we made three very important changes: 
  • Rows are no longer hierarchical, even when the grid is grouped; 
  • The Rows collection itself contains only GridViewDataRowInfo objects. This way it is much easier to access various features this data-record wrapper offers; 
  • And the most important one – Rows now consists of actual data objects only (wrapped up in GridViewDataRowInfo’s, of course). For those of you who still need to access various rows product of data-calculations (group headers, summaries, etc) we have introduced an easily accessible hierarchical structure!

We are confident that these changes drastically improve the usability of the grid and present a new way of working with data. The new setup has been designed with developers in mind and we think that they will find the new approach much more reasonable and easy to use.

Another part that was changed significantly relates to grouping and filtering APIs. For example, when grouping was used, the API did not keep in synch the visual appearance of the data in the grid with the grid’s (grouping) header. Well, these problems are no more!

Other changes:

  • Columns are now a collection of GridViewDataColumns –properties like Sort, Filter, FieldName (prev. DataField) are now much easier to access; 
  • Aggregates have been improved; 
  • A brand new set of APIs for managing filtering has been introduced: FilterExpression, predicates, etc. Filters are assignable to each grid column, immediately affecting grid’s UI.


We will keep you updated on the progress with the product. We are still working on the performance measures, and I will post them here as soon as they are ready.

In case you would like to get your hands on the new version before the official release (Q1 2008), please drop me a line below - I will be glad to enter your name for the pre-release in January.

Again, I will be happy to address any questions you may have about the new version. In case you want to see some particular performance tests, please let me know here so that I can provide them to you.


Comments are disabled in preview mode.