We had a similar problem (see this post) which was resolved with CSS classes.  If you're not using CSS classes to configure your grid, you'll need to do that.  We had a dramatic boost in performance after this.

Note that IE is VERY slow when using DOM when it comes to large arrays.  There is no getting around it unless you replace all the HTML yourself which wouldn't really be something you'd want to do with this control as it defeats its purpose.  I'd recommend sticking with smaller rows loaded by default and then give the user the option to load more or to configure how many rows they want to load.

Good luck.

Thanks for your post A Yousif. We are using CSS already as you can see in the sample I attached in my original post, so there is nothing to improve. We cannot show less data - all rows are needed at once. We even need to be able to sort them several times by different columns. So I still like to hear an official statement from Intersoft.

To repeat my final question to Intersoft here:

In short, can you tell me:

• Isn't IE6 a supported browser of WebGrid 6?
• Are 3500 rows just too much for a web application / for WebGrid?
• Is there any big difference with a newer WebGrid version? If yes, what times do you get there with IE6 client?

Please also consult your sales department before answering. Thanks.

I’ve checked your sent sample and managed to reproduce the issue on my local test.
I need more time to investigate the problematic behavior. I’ll keep you updated with news regarding this issue.

• Isn't IE6 a supported browser of WebGrid 6?

Both WebGrid 6 and WebGrid 7 (the latest version of WebGrid, currently) are compatible with Internet Explorer 6.

• Are 3500 rows just too much for a web application / for WebGrid?

This issue is actually not WebGrid’s issue. It is caused by the rendering engine that belongs to the Internet Explorer itself. Render a table that has 3500 rows is not that easy for web application. Not only WebGrid, but I believe event an html table itself.

• Is there any big difference with a newer WebGrid version? If yes, what times do you get there with IE6 client?

When users expanded a group row, WebGrid loads the child rows on demand via AJAX callback and then seamlessly inject it into the group row element. This gives users the feel of working with desktop apps.

Everything is good until your users accidentally grouped a data resulting with large amount of rows per group. It becomes worse when the Grid is working in client-binding since the rendering operation is done in the client-side. Imagine looping through thousands of records to perform string-extensive operations, the browser itself naturally refuse to complete the operation. And hence, you’ll get a prompt that ask you whether you want to stop or continue the script. Although you can choose to continue the script, it will still take several seconds to complete. This is certainly not a desirable result for most of today’s users who expecting applications with rich experiences.

WebGrid development team has implemented the VirtualLoad paging capability. When enabled, virtual load retrieves only the first subset of data and then smartly loads the rest records as user scroll downward.

With the new group row paging capability, you no longer have to worry how much data your Grid is presenting, whether they are grouped or not, whether they are filtered or not, WebGrid will display your data in the same timely fashion – consistently.

However, this kind of feature is not available yet for self-reference structure. It is planned to be implemented in next year. So there should be no big difference between WebGrid 6 and the newer WebGrid version.

For more detail about this feature, please check this post at following link, http://intersoftpt.wordpress.com/2010/02/10/virtual-group-paging-with-client-binding-in-depth/.

Hope this helps.