Changeset 205547 in webkit
- Timestamp:
- Sep 7, 2016 8:54:38 AM (8 years ago)
- Location:
- trunk/Source/WebKit2
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
trunk/Source/WebKit2/ChangeLog
r205545 r205547 1 2016-09-07 Emanuele Aina <emanuele.aina@collabora.com> 2 3 [GTK] Clarify frame callbacks behaviour in Wayland compositor 4 https://bugs.webkit.org/show_bug.cgi?id=161683 5 6 Reviewed by Carlos Garcia Campos. 7 8 The way we fire frame callbacks in the nested Wayland compositor can 9 be puzzling to developers expecting Wayland semantics, but since we 10 have our own mechanism to handle synchronization we don't care much 11 about them. Add a comment to avoid surprised Wayland developers. 12 13 * UIProcess/gtk/WaylandCompositor.cpp: 14 (WebKit::WaylandCompositor::Surface::commit): 15 1 16 2016-09-07 Csaba Osztrogonác <ossy@webkit.org> 2 17 -
trunk/Source/WebKit2/UIProcess/gtk/WaylandCompositor.cpp
r205475 r205547 232 232 m_webPage->setViewNeedsDisplay(IntRect(IntPoint::zero(), m_webPage->viewSize())); 233 233 234 // From a Wayland point-of-view frame callbacks should be fired where the 235 // compositor knows it has *used* the committed contents, so firing them here 236 // can be surprising but we don't need them as a throttling mechanism because 237 // rendering synchronization is handled elsewhere by WebKit. 234 238 auto list = WTFMove(m_frameCallbackList); 235 239 for (auto* resource : list) {
Note: See TracChangeset
for help on using the changeset viewer.