Skip to content
Permalink
Browse files
Tapping on an apple.com tab in tab overview stutters when switching t…
…o it

https://bugs.webkit.org/show_bug.cgi?id=159904
<rdar://problem/27192350>

Reviewed by Simon Fraser.

* UIProcess/mac/RemoteLayerTreeDrawingAreaProxy.mm:
(WebKit::RemoteLayerTreeDrawingAreaProxy::waitForDidUpdateViewState):
In any case where we get to waitForDidUpdateViewState (usually a tab switch),
if we have an outstanding didUpdate message, the Web process will not commit
a new layer tree until it receives the didUpdate message. However, since
waitForDidUpdateViewState synchronously blocks the UI process, we also
won't *send* the didUpdate message, so we block for the full timeout duration.

Instead, if we get to waitForDidUpdateViewState, just send the didUpdate without
waiting for the DisplayLink or anything else, because calling rAF slightly too
quickly, once, is certainly better than blocking the UI process for a whole second.


Canonical link: https://commits.webkit.org/178069@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@203385 268f45cc-cd09-0410-ab3c-d52691b4dbfc
  • Loading branch information
hortont424 committed Jul 19, 2016
1 parent 2b47d98 commit dc0a1c6e1aa579681b89dec482d4a826ef7dc896
Showing with 25 additions and 0 deletions.
  1. +20 −0 Source/WebKit2/ChangeLog
  2. +5 −0 Source/WebKit2/UIProcess/mac/RemoteLayerTreeDrawingAreaProxy.mm
@@ -1,3 +1,23 @@
2016-07-18 Tim Horton <timothy_horton@apple.com>

Tapping on an apple.com tab in tab overview stutters when switching to it
https://bugs.webkit.org/show_bug.cgi?id=159904
<rdar://problem/27192350>

Reviewed by Simon Fraser.

* UIProcess/mac/RemoteLayerTreeDrawingAreaProxy.mm:
(WebKit::RemoteLayerTreeDrawingAreaProxy::waitForDidUpdateViewState):
In any case where we get to waitForDidUpdateViewState (usually a tab switch),
if we have an outstanding didUpdate message, the Web process will not commit
a new layer tree until it receives the didUpdate message. However, since
waitForDidUpdateViewState synchronously blocks the UI process, we also
won't *send* the didUpdate message, so we block for the full timeout duration.

Instead, if we get to waitForDidUpdateViewState, just send the didUpdate without
waiting for the DisplayLink or anything else, because calling rAF slightly too
quickly, once, is certainly better than blocking the UI process for a whole second.

2016-07-18 Carlos Alberto Lopez Perez <clopez@igalia.com>

[GTK] ENABLE_OPENGL=OFF build broken since r201802
@@ -423,6 +423,11 @@ - (void)pause

void RemoteLayerTreeDrawingAreaProxy::waitForDidUpdateViewState()
{
// We must send the didUpdate message before blocking on the next commit, otherwise
// we can be guaranteed that the next commit won't come until after the waitForAndDispatchImmediately times out.
if (m_didUpdateMessageState != Sent)
didRefreshDisplay(monotonicallyIncreasingTime());

static std::chrono::milliseconds viewStateUpdateTimeout = [] {
if (id value = [[NSUserDefaults standardUserDefaults] objectForKey:@"WebKitOverrideViewStateUpdateTimeout"])
return std::chrono::duration_cast<std::chrono::milliseconds>(std::chrono::duration<double>([value doubleValue]));

0 comments on commit dc0a1c6

Please sign in to comment.