Is there a reason that, instead of updating the rules that apply to the given column, you don't instead add a "x-hidden-column" class to the elements in question?
Adding a css class to existing cells would probably be slower (depending on the number of rows). However, the big problem is it wouldn't work across changes to the data.
How many columns/rows do you have? For me it is blazing fast. But my grids never have more than 25 rows/5-6 columns.
Jack Slocum
Ext JS Founder
Original author of Ext JS 1, 2 & 3.
Twitter: @jackslocum jack@extjs.com
I used Firebug's profile feature to see why the Grid was so slow during a resize, and it was clearly updateRule. I came upon this article from Microsoft in which they say to avoid switching classes and style rules.
I'm sure there must be a way to change the width of the columns without calling updateRule. I think updateRule was needed because the Grid's cells were in span and div elements, but from what I can see in the beta-2 GridView.js code it looks like they are now in an actual table.
With each new release, the code has gotten better. Thanks. I'm looking forward to the next one.
What about each column being a float:left div? Each cell would be a regular div, and they'd just stack up in the columns.
Column resizing and moving might be fast then. No need to manipulate stylesheet rules, just operate directly on the column div.
Of course there would then be the problem of ensuring that all the cells in a row have the same height, so you might just be shifting the problem from one dimension to another!.
Looking at the beta-2 "Array Grid Example" with Firebug it looks like the rows of the Grid are all in a table.
The table has no THEAD, just a TBODY. Why not add a THEAD with one row in it, and simply change the "style" of the cells in the THEAD with the new width? It should be much faster than using updateRule.
MarkT, I tried your suggestion early on but setting the width of cell is not respected cross browser (tables have their own layout rules, even with table-layout:fixed; ).
I don't know how many times I can say this:
The problem has nothing to do with updating the CSS rule.
I have investigated this to the max and the problem is it causes a reflow of many elements and for a large DOM that is slow. If you set the width of 1 element and it causes a width shift that causes a reflow for for a bunch of other elements, it has the same lag as updating the rule.
The only way I have found to speed it up is to make a stripped down grid view that doesn't do text truncation and therefore has less elements to reflow. Hiding overflow seems to be the bottleneck in my tests.
Jack Slocum
Ext JS Founder
Original author of Ext JS 1, 2 & 3.
Twitter: @jackslocum jack@extjs.com