[Webkit-unassigned] [Bug 13443] New: FIXME: computeAbsoluteRepaintRect() ignores control clip rects

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sat Apr 21 22:50:06 PDT 2007


           Summary: FIXME: computeAbsoluteRepaintRect() ignores control clip
           Product: WebKit
           Version: 522+ (nightly)
          Platform: Macintosh
        OS/Version: Mac OS X 10.4
            Status: NEW
          Severity: Minor
          Priority: P3
         Component: Layout and Rendering
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: mitz at webkit.org

[Following up on bug 13391].

RenderBox::computeAbsoluteRepaintRect() ignores the lightweight clip used by
some form controls, the reason being that when it's called during layout,
controlClipRect() returns a wrong result. In the context of a child of the
control repainting during layout, you need the control's clip rect before
layout. I have considered several ways to fix this:

1) Cache the clip rects in the controls themselves post layout(). This is a
very fast and simple solution, but it increases the memory footprint of
controls for information that's basically needed only during layout.

2) Cache the clip rects in a hash table kept in the RenderView. Controls can
cache their current clip rect when entering layout() and delete it from the
hash before returning from layout().

3) Similar to 2) but use a stack, so each control pushes its clip rect onto the
stack. Since controls are very rarely nested, computeAbsoluteRepaintRect()
could simply walk the stack looking for |o| (no need to pass the current stack
pointer when recurring).

4) Maintain a true clipping rect stack in RenderView, including the "current
clip", and pushing both control clip and layer clip. This will fix bug 11489 as

The disadvantage of 2-4 is the complexity, which includes having to keep a
"during layout" code path separate from the "after layout" code path. I'd go
with 1) or 2), assuming bug 11489 will be addressed by flexbox changes.

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

More information about the webkit-unassigned mailing list