| Summary: | Repaint throttling mechanism | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Antti Koivisto <koivisto> | ||||||
| Component: | Page Loading | Assignee: | Nobody <webkit-unassigned> | ||||||
| Status: | RESOLVED FIXED | ||||||||
| Severity: | Normal | CC: | hyatt, manyoso, staikos | ||||||
| Priority: | P2 | ||||||||
| Version: | 528+ (Nightly build) | ||||||||
| Hardware: | Mac | ||||||||
| OS: | OS X 10.5 | ||||||||
| Attachments: |
|
||||||||
|
Description
Antti Koivisto
2009-03-04 10:28:23 PST
Created attachment 28273 [details]
patch
This patch has the feature enabled and bunch of debugging printfs
This looks pretty cool. The biggest issue is just catching all of the things that should not be throttled. You caught user events, but I think you need to catch all the ways a page can animate on its own as well. These include: setTimeout marquees CSS Animations and Transitions Animated GIFs We have to make sure none of the situations where a page paints itself because of animations end up getting throttled. Oh, <video> also. <video> shouldn't be throttled while painting either. SMIL. Created attachment 28281 [details]
some cleanups
I agree that a desktop targeted version of this should prefer smooth animations over reduces repaints. On slower CPUs the balance is different.
This patch does not enable the delays by default.
Comment on attachment 28281 [details]
some cleanups
This looks fine to me. Can you maybe add a FIXME comment (similar to what you said in the bug) to the place where the constants are defined that this is primarily for mobile devices now, and that we might want to consider a version for the desktop that doesn't throttle animations?
r=me
Sending JavaScriptCore/ChangeLog Sending JavaScriptCore/wtf/Platform.h Sending WebCore/ChangeLog Sending WebCore/loader/FrameLoader.cpp Sending WebCore/page/EventHandler.cpp Sending WebCore/page/FrameView.cpp Sending WebCore/page/FrameView.h Transmitting file data ....... Committed revision 41431. |