Bug 11899 - framesets force full-view repaint unnecessarily
Summary: framesets force full-view repaint unnecessarily
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 420+
Hardware: PC Windows XP
: P2 Normal
Assignee: Nobody
URL: http://stein.cshl.org/WWW/CGI/example...
Keywords:
Depends on:
Blocks:
 
Reported: 2006-12-20 15:59 PST by Dex Deacon
Modified: 2007-01-26 18:02 PST (History)
1 user (show)

See Also:


Attachments
only call setNeedsLayout(true) if the view's size has changed (1.44 KB, patch)
2006-12-20 18:16 PST, Dex Deacon
hyatt: review-
Details | Formatted Diff | Diff
call setChildNeedsLayout on framesets (1.19 KB, patch)
2007-01-08 13:53 PST, Dex Deacon
mjs: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dex Deacon 2006-12-20 15:59:24 PST
Visit the sample URL, and click in the entry box to focus it.  As the cursor flashes, repaints are issued.  However, because the entry box is within a frameset, the repaint is applied to the full contents of the frameset rather than just the entry box.

(You can check this by adding a printf() in WebFrame::paint() to print out ps.rcPaint.  Compare that to what happens when you just navigate to the frame with the entry box - http://stein.cshl.org/WWW/CGI/examples/frameset.cgi/query).

This happens because on every call to FrameView::layout, the following code is executed:
                if (body->hasTagName(framesetTag)) {
                    body->renderer()->setNeedsLayout(true);
This seems unnecessary and wrong.  I believe the correct fix is to remove the call to setNeedsLayout.  I'll make sure that doesn't break the layout tests, and submit a patch.
Comment 1 Dave Hyatt 2006-12-20 16:32:00 PST
Layout is only done if needed.  You're looking at buggy Windows code.  Repaints do not trigger a relayout normally, but the buggy windows code always calls layout over and over when painting (even when no layout is necesary).  This will lead to many strange bugs.

That said, I do agree that setNeedsLayout here is wrong.  It should be setChildNeedsLayout just like the body tag code path.
Comment 2 Dex Deacon 2006-12-20 18:16:07 PST
Created attachment 11941 [details]
only call setNeedsLayout(true) if the view's size has changed
Comment 3 Dex Deacon 2006-12-20 18:34:49 PST
Sorry Dave, I didn't see your comment until now.

Do you mean to simply replace the call to setNeedsLayout() with setChildNeedsLayout()?  That does seem to resolve the speed issues I was noticing as a result of this bug.

Or do you mean to perform the same checks as the body tag path as well?

Either way, I don't understand why setChildNeedsLayout() is better here :).
Comment 4 Dave Hyatt 2006-12-20 19:32:38 PST
Comment on attachment 11941 [details]
only call setNeedsLayout(true) if the view's size has changed

The WebKit side of the WIndows code is buggy and it is causing layout() on FrameView to get called when it shouldn't.

Cursor blinking should not cause you to re-enter layout, but it does so because WebView on Win32 is buggy.

You should not technically even have to patch any cross-platform code to fix the Windows bug.
Comment 5 Dex Deacon 2007-01-03 13:04:47 PST
Shouldn't the code still be fixed to use setChildNeedsLayout() instead of setNeedsLayout()?  That's still a bug with the WebCore code (it also has the benefit of helping the buggy Windows repaint issue).
Comment 6 Dex Deacon 2007-01-08 13:53:35 PST
Created attachment 12308 [details]
call setChildNeedsLayout on framesets
Comment 7 Maciej Stachowiak 2007-01-26 14:36:45 PST
Comment on attachment 12308 [details]
call setChildNeedsLayout on framesets

Hyatt says this is ok. r=him.
Comment 8 Sam Weinig 2007-01-26 18:02:36 PST
Landed in r19170.