[Webkit-unassigned] [Bug 33150] Do not render the full frame when there is some elements with fixed positioning

[bugzilla-daemon at webkit.org]

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





--- Comment #88 from Benjamin Poulain <benjamin.poulain at nokia.com>  2010-03-29 01:39:29 PST ---
(In reply to comment #87)
> How to reproduce:
> 
> - Run Chromium or QtLauncher
> - Download
> http://chromium.googlecode.com/issues/attachment?aid=8184776065656844667&name=testcase.xht
> and open it with your browser
> - You would notice the image will be wrongly rendered when you scroll

I cannot reproduce the problem with QtLauncher (use FrameView) nor Safari trunk
(no FrameView, platformWidget).
I don't have Chronium trunk, I will ask Andreas if he can test the issue.

The code should not go at all to scrollContentsFastPath() if you have a
platformWidget, I need to investigate that. It is strange I don't have the
problem with Safari.

> 1. Comment 45 said we won't change the behavior when platformWidget is
> non-NULL, but the change for useSlowRepaints() seems to be changing the
> behavior.

It shouldn't.
Before the patch, WebKit was doing a full update as soon as a fixed element was
in the page (check the change of RenderObject). 

Now it only does so if you have a PlatformWidget (that is why I needed
addFixedObject/removeFixedObject) and changed useSlowRepaints().

> 2. I wasn't sure why we call invalidateContentsAndWindow() instead of scroll()
> when fast scroll fails (this should not be related the issue I'm reporting
> because scrollContentsFastPath returns true with the testcase).
> 
> > -       // FIXME: Find a way to scroll subframes with this faster path
> > -       hostWindow()->scroll(-scrollDelta, scrollViewRect, clipRect);
> > +        // FIXME: Find a way to scroll subframes with this faster path
> > +        if (!scrollContentsFastPath(-scrollDelta, scrollViewRect, clipRect))
> > +            hostWindow()->invalidateContentsForSlowScroll(updateRect, false);

The call to scrollContentsFastPath() returns false if it is not possible to use
the fast path. In that case, we go the old way and do a full repaint.


> Benjamin, could you look into this? 

Sure. I have to look at 36686, 36652 and this one. I will try to reproduce the
issue as soon as I get my hand on a recent Chronium.

> If it will take a few days to fix this
> issue, I'd like to revert this patch for now (and hopefully a refined patch
> will be landed with thorough tests).

I would really, really prefer if we can avoid a revert. Landing this patch as
been a pain in the ass, nobody was willing to review it, it stayed in queue for
months.

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