Hi
I've the code of an old version of the infragistics suite (v2007.3) and I've found a very weird performance problem that arises when using IE8.
I'm reporting it because it is occurring also in your demo site that is using the version 2009.1, but I don't know if this problem has been solved in the hotfix you have released for the 2009.1.
The problem is in this javascript procedure: file 'ig_webgrid_dom.js', function "init" contained in object igtbl_ptsRow. The actual problem is this line of code
tr.cells[j].id = cellId.join(
"_");
That line of code (the setting of the id of a cell) is very very very slow under IE8, but has no impact with IE7.
Can you tell me whether this issue has been solved in v2009.1 hotfix?
Is the source code of the hotfix available upon buying v2009.1?
Best regards, Andrea Pirola
Hello,
No, this problem is not resolved in the latest hot fix. Honestly I am not sure how we'd be able to without changing logic and therefore potentially introducing more problems.
In general IE8 behaves horribly when it comes to manipulating tables. Hopefully MS will take care of it in the first service pack for IE8. I'd suggest you to bring it to their attention as well by going to connect.microsoft.com
The source code is available to all customers with subscription.
first of all, permit me to give you a possible solution for IE8. The slowness of IE8 setting the IDs of the cells is much more evident when the html table has defined the <col> tags. I've provided two example files.
"TestTableWithCol.html" is a 1K cell table with <col> tags.
"TestTableWithoutCol.html" is a 1K cell table without <col> tags
A JS function iterates over all the cells and set the IDs of each of them. The difference in performance is terrible (without cols is 6 times faster more or less). So, is it possible, in the newer versions of the grid to render it without those tags? The widths of the columns could be moved to the table header, couldn't they?
I'm sorry for stressing the point, but the problem is also worse in the 2009v1 that I've tested as a trial than in 2007v3 I've bought, because the in 2007v3 the set of the ids is invoked only when a row is actually clicked, instead in 2009v1 the set of the IDs is performed for all the rows on the load of the page (I don't remember which function calls it). This makes the rendering of the grid really slower in the new version than in the older one (I've a grid with 200 hundred rows that takes 12 seconds to display).
Unfortunately that would call for a redesign of the entire client side functionality of the grid.
In our new line of controls we have a new grid called WebDataGrid. It is not using col elements nor assigning ids on the cells. So according to your tests it should be a lot faster than UltraWebGrid.
We did find the root cause of this problem and it is going to be fixed asap.
If you don't use the FilterRow in your grid you can temporarily apply the following workaround. At the bottom of your for in the aspx add this script block:
<script type="text/javascript">
igtbl_Grid.prototype._alignFilterRow = function() { };
</script>
I am sorry I have misled you about this in the beginning.
Thanks for your good solution. But I dont understand why the issue can solve when we hack the align filter row? Can you please explain more?
This sounds to me like a completely different issue. I'd suggest you asking about it in the WARP forum, or contact the dev support. Thanks.
Turning off the view state improved the performance, however, IE8 does a full post back for Async calls and that produces unwanted result for me. IE7, IE6,Firefox, Safari work fine. Is there something specific for IE8 that can be done such that it does not do the full postback? I am using WebAsynchRefreshPanel.
The service release does fix the problem, except for the Async refresh. Is there something else that needs to be done for async refresh. I am not using Filters and may be turning that off on Async may help. But need to know how?
regards,
Rajiv.
If the provided workaround does not make a difference in your case, it is probably something else. I would recommend you to contact dev support for an in-depth evaluation. Thanks.