Bernd wrote: > Column rebalancing on large tables is not really cheap so avoiding it > seems reasonable to me. If we don't need that, the better.
That's a separate issue from the one I'm trying to solve, though. Right now we do a rebalance on any content change inside any child of the table, basically, because anything that affects min and pref widths can affect it. We can try to optimize it, I guess, but it seems to be cheaper than reflowing all the rows... > I think you can use the cellmap methods to estimate the effect of a cell > insertion/removal. Thats the place where rowspans are handled. > > 1. If we rebuild the cellmap you have to reflow all rows. > 2. If the cheaper methods are used one can retrieve the affected rows > from them. OK. Where would be a good place to hook in to get that info? > Further there are an quite subtle code paths that set the cell heights. > CalculateRowHeights (see the comment at > http://lxr.mozilla.org/seamonkey/source/layout/tables/nsTableRowGroupFrame.cpp#547) > Yes. The goal is to skip this when possible. ;) > If there are height constrains on the table, rowgroup, rows or cells > things become complicated and you are probably better off by reflowing > all rows. Its also pretty nasty if the special height reflow is invoked. Height constraints on the table just mean we fall back on recalculating all row heights right now. I'm happy with that. It's hard to run into tables with a few tens of thousands of rows _and_ a constrained height. In fact, the only case I _really_ badly want to optimize is appending to the last row in the last rowgroup of the table. Or appending a row to this rowgroup. Or appending a rowgroup to the end of the table. Things that the parser does, basically. -Boris _______________________________________________ dev-tech-layout mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-layout
