Bug 86651 - FrameView::scrollContentsFastPath should use painted area to determine whether to drop out of the fast path
Summary: FrameView::scrollContentsFastPath should use painted area to determine whethe...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2012-05-16 10:23 PDT by Tim Horton
Modified: 2012-05-16 13:54 PDT (History)
6 users (show)

See Also:


Attachments
patch (5.63 KB, patch)
2012-05-16 10:29 PDT, Tim Horton
simon.fraser: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Horton 2012-05-16 10:23:40 PDT
<rdar://problem/11459243>

FrameView::scrollContentsFastPath has a fixedObjectThreshold of 5: if there are more than 5 fixed-positioning elements on the page, it will fall out of the fast (blit) path and repaint everything.

This doesn't make sense - causing repaints of the whole page just because someone used 5 (or 10, or whatever) tiny fixed-position elements is wasteful (and vice versa, blitting the whole window and then just going ahead and redrawing it all because someone used only one enormous fixed-position element also doesn't make sense).

We can make trivial use of regions and threshold based on percentage of the view that will need to be repainted by fixed-position elements.

I've tested a few different thresholds with an internal test; 50% seems to work relatively well, but the ideal value is hard to determine and likely depends on hardware.

I have a patch.
Comment 1 Tim Horton 2012-05-16 10:29:48 PDT
Created attachment 142292 [details]
patch
Comment 2 Tim Horton 2012-05-16 11:41:47 PDT
http://trac.webkit.org/changeset/117313
Comment 3 Adrienne Walker 2012-05-16 12:23:10 PDT
Ooh, that's excellent.  That seems like a much better heuristic.