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

Thu Sep 8 10:26:01 PDT 2011

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

--- Comment #19 from Konstantin Shcheglov <scheglov at google.com>  2011-09-08 10:26:00 PST ---

> I was hinting at the middle "Once we have all the style sorted, we then do individual passes." Even if you kept the gist of the comment, I found that this part helped understand the articulation between the 2 parts you split.
> How about for the following comment:
> 
> // Using our cached sorted styles, we then do individual passes, painting each style of border from lowest precedence to highest precedence.

  OK

> >   Well, probably I just don't know some trick how it is accessed from JS.
> >   Can you give me hint?
> >   Is there way to get collapsed border values in JS?
> 
> Sure, here is how you can access the border value through JS:
> 
> var cell = document.getElementById('thisCell');
> getComputedStyle(cell, '').borderLeftWidth

  I don't observe that in JS you access collapsed border values.
  I think that collapsed borders are paint/presentation feature instead of style feature.

    <body onload="test()">
        <table style="border-collapse:collapse; border:2px solid blue">
            <tr>
                <td style="border:4px solid lime" id="foo"/>
                <td style="border-left:6px solid yellow" id="bar"/>
                <td/>
            </tr>
        </table>
        <div id="console"/>
    </body>

            function test() {
                fooCell = document.getElementById("foo");
                barCell = document.getElementById("bar");
                log("foo borderRightWidth: " + getComputedStyle(fooCell, '').borderRightWidth);
                log("bar borderLeftWidth: " + getComputedStyle(barCell, '').borderLeftWidth);
            }

      RenderBlock {DIV} at (0,70) size 784x56
        RenderBlock {P} at (0,0) size 784x20
          RenderText {#text} at (0,0) size 163x19
            text run at (0,0) width 163: "foo borderRightWidth: 4px"
        RenderBlock {P} at (0,36) size 784x20
          RenderText {#text} at (0,0) size 156x19
            text run at (0,0) width 156: "bar borderLeftWidth: 6px"

> Maybe more importantly, all the virtual border* method on RenderTableCell will still trigger a recomputation and completely miss the cache. The invocations of those function are spread in the rendering code but they are nevertheless important.

  RenderTable.paintObject() asks every RenderTableCell about its collapsed border, so if table is huge, this takes a lot of time.
  In contrast RenderTableCell talks only with its direct parents and siblings.
  Single RenderTableCell::collapsedStartBorder() method requires about 1/1000 ms on my computer.

  Only place where this is important is table loading, this calls border*() methods hundreds thousands times.
  For test case replacing collapsed*Border() with NOP reduces reload time from 4500ms to 2900ms.
  As I can see, this happens because of periodical re-parsing and re-layout during loading.
  No sure however what part of test case causes this - single table with 10000 rows or 1000 tables with 10 rows.
  So, it seems that it worth optimization.

  Can we however do this in separate bug?
  RenderTable.paintObject() still worth optimization to avoid visiting every cell on each paint.

> >   Should I move CollapsedBorderValues into RenderTable.h instead?
> 
> About CollapsedBorderStyles, you can move it to RenderTable.h. It looks like part of your problem arise from the fact that RenderTableCell / RenderTableSection are doing unneeded #include and could use some forward-declarations. You could redefine the symbol if moving is proving problematic but I think you would need to solve the #include issue then.

  Unfortunately with forward declarations we can almost do the trick, but we loose ability to inline toRenderTable(), which is declared in RenderTable.h.
  So, I end up moving CollapsedBorderValues as inner class of RenderTable.

> I feared setting the size to 0 in CollapsedBorderValues would actually hurt other use cases: when you *do* need to collect borders, you can easily need 100 entries in your Vector. 100 entries is only 25 cells (4 borders per cell). You could mitigate that by pre-allocating the Vector before collecting your borders as you can estimate the size needed.

  As I can see, even for huge table CollapsedBorderValues contains only 2 elements, because we remember only unique CollapsedBorderValue objects.

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