Rebaselines fast/repaint/fixed.html to accomodate scrolling change introduced by r26143.

That commit should have also included the following commit message:

This patch avoids unnecessary layout work by calling
FrameView::layoutIfNecessaryRecursive() from WebFrameImpl::Layout() rather than
manually recursing through frames and calling FrameView::layout()

This patch should greatly help out slow scrolling on sites like gmail.  Gmail
has some position:fixed elements that prevent the renderer from simply blitting
on a scroll event, so it has to repaint the onscreen elements.  In order to
avoid painting a stale or incorrect image the renderer has to check that layout
is up-to-date before painting which invokes WebFrameImpl::Layout().  Previously,
this called FrameView::layout() for each frame.  This meant a lot of extra work
was being done even if the render tree was up to date and didn't need any more
layout work.  This patch calls FrameView::layoutIfNeededRecursive() instead
which checks the needsLayout() flag on each FrameView in the tree.  In the case
of gmail, the onscroll handler does not invalidate layout so this call returns
nearly instantly.  This matches WebKit/Safari behavior.

On my workstation the times for scrolling a large thread in gmail look like
this:

Before: 40ms of layout, 19ms of painting on each scroll event
After: 0ms of layout, 19ms of painting on each scroll event

This changes the pixel results of fast/repaint/fixed.html, but the post-change
results appear to be correct.

Review URL: http://codereview.chromium.org/196112

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@26157 0039d316-1c4b-4281-b951-d872f2087c98

0 files changed, 0 insertions, 0 deletions