Changeset 203385 in webkit


Ignore:
Timestamp:
Jul 18, 2016 5:24:28 PM (8 years ago)
Author:
timothy_horton@apple.com
Message:

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.

Location:
trunk/Source/WebKit2
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • trunk/Source/WebKit2/ChangeLog

    r203384 r203385  
     12016-07-18  Tim Horton  <timothy_horton@apple.com>
     2
     3        Tapping on an apple.com tab in tab overview stutters when switching to it
     4        https://bugs.webkit.org/show_bug.cgi?id=159904
     5        <rdar://problem/27192350>
     6
     7        Reviewed by Simon Fraser.
     8
     9        * UIProcess/mac/RemoteLayerTreeDrawingAreaProxy.mm:
     10        (WebKit::RemoteLayerTreeDrawingAreaProxy::waitForDidUpdateViewState):
     11        In any case where we get to waitForDidUpdateViewState (usually a tab switch),
     12        if we have an outstanding didUpdate message, the Web process will not commit
     13        a new layer tree until it receives the didUpdate message. However, since
     14        waitForDidUpdateViewState synchronously blocks the UI process, we also
     15        won't *send* the didUpdate message, so we block for the full timeout duration.
     16
     17        Instead, if we get to waitForDidUpdateViewState, just send the didUpdate without
     18        waiting for the DisplayLink or anything else, because calling rAF slightly too
     19        quickly, once, is certainly better than blocking the UI process for a whole second.
     20
    1212016-07-18  Carlos Alberto Lopez Perez  <clopez@igalia.com>
    222
  • trunk/Source/WebKit2/UIProcess/mac/RemoteLayerTreeDrawingAreaProxy.mm

    r202297 r203385  
    424424void RemoteLayerTreeDrawingAreaProxy::waitForDidUpdateViewState()
    425425{
     426    // We must send the didUpdate message before blocking on the next commit, otherwise
     427    // we can be guaranteed that the next commit won't come until after the waitForAndDispatchImmediately times out.
     428    if (m_didUpdateMessageState != Sent)
     429        didRefreshDisplay(monotonicallyIncreasingTime());
     430
    426431    static std::chrono::milliseconds viewStateUpdateTimeout = [] {
    427432        if (id value = [[NSUserDefaults standardUserDefaults] objectForKey:@"WebKitOverrideViewStateUpdateTimeout"])
Note: See TracChangeset for help on using the changeset viewer.