Changeset 181133 in webkit
- Timestamp:
- Mar 5, 2015 8:38:01 PM (9 years ago)
- Location:
- trunk/Source/WebCore
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
trunk/Source/WebCore/ChangeLog
r181123 r181133 1 2015-03-05 Chris Dumez <cdumez@apple.com> 2 3 Document::recalcStyle() shouldn't call viewportContentsChanged() if there is a pending layout 4 https://bugs.webkit.org/show_bug.cgi?id=142140 5 6 Reviewed by Darin Adler. 7 8 Stop calling FrameView::viewportContentsChanged() in Document::recalcStyle() 9 if there is a layout pending to avoid doing unncessary work. If there is a 10 layout pending, we don't need to do anything because viewportContentsChanged() 11 will be called after layout. 12 13 We only need to call FrameView::viewportContentsChanged() in 14 Document::recalcStyle() if a style recalc does not cause a layout. For e.g. 15 a '-webkit-transform' could make an animated GIF visible without causing a 16 layout, in which case we need to resume the animated GIF after style recalc. 17 18 No new tests, already covered by: 19 fast/images/animated-gif-webkit-transform.html 20 21 * dom/Document.cpp: 22 (WebCore::Document::recalcStyle): 23 1 24 2015-03-05 Dean Jackson <dino@apple.com> 2 25 -
trunk/Source/WebCore/dom/Document.cpp
r180867 r181133 1791 1791 1792 1792 // Some animated images may now be inside the viewport due to style recalc, 1793 // resume them if necessary. 1794 frameView.viewportContentsChanged(); 1793 // resume them if necessary if there is no layout pending. Otherwise, we'll 1794 // check if they need to be resumed after layout. 1795 if (!frameView.needsLayout()) 1796 frameView.viewportContentsChanged(); 1795 1797 1796 1798 // As a result of the style recalculation, the currently hovered element might have been
Note: See TracChangeset
for help on using the changeset viewer.