[Webkit-unassigned] [Bug 64546] Redrawing dirty parts of a large table is very slow

Wed Aug 31 14:11:36 PDT 2011

https://bugs.webkit.org/show_bug.cgi?id=64546

Julien Chaffraix <jchaffraix at webkit.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hyatt at apple.com

--- Comment #4 from Julien Chaffraix <jchaffraix at webkit.org>  2011-08-31 14:11:36 PST ---
(CC'ing dhyatt as he is the table expert)

> One possible approach is listening styleDidChange() in every cell, row,  etc and notify parent table that cache become invalid. Plus do same for addChild() and removeChild(). 

It's extremely complicated to do it this way as there are cross-dependencies:
* a cell changing its border style would (potentially) impact all the surrounding cells.
* a table changing its border may impact all or some cells.
* ...

> What do you think?

You will have to watch for memory explosion as tables are already using a lot of memory (see bug 23193). One problem is that we don't know the usage of "border-collapse" in the wild to know if it is worth the investment for each cell (likely not but we have no clue).

Also our table coverage is less than perfect: I tested some simple caching schemes that showed very promising improvements but were completely wrong and yet our tests only caught some the badness.

> Any alternative ideas how to solve this?

Another (likely better) way would be to recompute them at layout time. There may be ways to mitigate the re-computations but I haven't thought about it enough.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.