[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


Benjamin Poulain <benjamin.poulain at nokia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #50355|0                           |1
        is obsolete|                            |
  Attachment #50355|commit-queue?               |
               Flag|                            |
  Attachment #50386|                            |review?, commit-queue?
               Flag|                            |




--- Comment #78 from Benjamin Poulain <benjamin.poulain at nokia.com>  2010-03-10 02:45:57 PST ---
Created an attachment (id=50386)
 --> (https://bugs.webkit.org/attachment.cgi?id=50386)
Repaint only the invalidated area after scrolling

> (From update of attachment 50355 [details])
> > +        // 2) update the area of fixed objets that has been invalidated
> 
> Typo.  This should be 'objects'.

Fixed :)

> > +        size_t fixObjectsCount = subRectToUpdate.size();
> > +        for (size_t i = 0; i < fixObjectsCount; ++i) {
> > +            IntRect updateRect = subRectToUpdate[i];
> > +            IntRect scrolledRect = updateRect;
> > +            scrolledRect.move(scrollDelta);
> > +            updateRect.unite(scrolledRect);
> > +            updateRect.intersect(rectToScroll);
> > +            hostWindow()->invalidateContentsForSlowScroll(updateRect, false);
> 
> I don't think you want to use 'invalidateContentsForSlowScroll' here.  Rather,
> I think 'invalidateContentsAndWindow' is the appropriate method call. 
> Otherwise you need to do it synchronously.

I have to admit I don't get the difference between
invalidateContentsForSlowScroll() and invalidateContentsAndWindow(). It seems
specific to the way Windows handle scrolling, I trust you on that one.


> I don't like that 'invalidateContentsForSlowScroll' is being called from a
> method named 'scrollContentsFastPath.'  This is confusing and I wonder if it
> points to a larger issue.  How about if scrollContentsFastPath returned true if
> it was possible, but false if not?  Then the latter could be invoked.

I agree, it is clearer if scrollContentsFastPath() never invoke the slow path.
I have made the modification you suggested.

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