Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(90)

Issue 1053653008: cc: Get BeginFrameArgs for BeginMainFrame while inside an impl frame. (Closed)

Created:
5 years, 8 months ago by mithro-old
Modified:
5 years, 7 months ago
Reviewers:
brianderson, enne (OOO)
CC:
chromium-reviews, cc-bugs_chromium.org
Base URL:
https://chromium.googlesource.com/chromium/src.git@master
Target Ref:
refs/pending/heads/master
Project:
chromium
Visibility:
Public.

Description

cc: Get BeginFrameArgs for BeginMainFrame while inside an impl frame. This patch also adds asserts to make sure that the assumption that ScheduledActionSendBeginMainFrame is only called inside an impl frame holds. Sending a BeginMainFrame requires BeginFrameArgs to be read from the LTHI which are only valid inside an impl frame. Due to needing to call BeginMainFrame asynchronously (as the comment inside the function mentions), the call could theoretically occur outside an impl frame. The likelihood of this effecting production is extremely low because impl frames are large but this problem does increase flakiness of the layer tree host unittests. BUG=346230 R=brianderson,enne

Patch Set 1 #

Patch Set 2 : Fixing timing around reading BFAs in scheduler flow. #

Unified diffs Side-by-side diffs Delta from patch set Stats (+17 lines, -7 lines) Patch
M cc/trees/single_thread_proxy.h View 1 2 chunks +2 lines, -1 line 0 comments Download
M cc/trees/single_thread_proxy.cc View 1 5 chunks +15 lines, -6 lines 0 comments Download

Messages

Total messages: 3 (2 generated)
mithro-old
5 years, 8 months ago (2015-04-24 07:11:52 UTC) #2
This patch currently doesn't work because
SingleThreadProxy::ScheduledActionSendBeginMainFrame() does a PostTask which
means the impl frame can end before BeginMainFrame actually occurs. See below;


void SingleThreadProxy::ScheduledActionSendBeginMainFrame() {
  TRACE_EVENT0("cc", "SingleThreadProxy::ScheduledActionSendBeginMainFrame");
  // Although this proxy is single-threaded, it's problematic to synchronously
  // have BeginMainFrame happen after ScheduledActionSendBeginMainFrame.  This
  // could cause a commit to occur in between a series of SetNeedsCommit calls
  // (i.e. property modifications) causing some to fall on one frame and some to
  // fall on the next.  Doing it asynchronously instead matches the semantics of
  // ThreadProxy::SetNeedsCommit where SetNeedsCommit will not cause a
  // synchronous commit.
  DCHECK(inside_impl_frame_)
      << "BeginMainFrame should only be sent inside a BeginImplFrame";
  MainThreadTaskRunner()->PostTask(
      FROM_HERE,
      base::Bind(&SingleThreadProxy::BeginMainFrame,
                weak_factory_.GetWeakPtr()));
}

I'm uncertain if when this occurs, it is okay to drop the BeginMainFrame onto
the floor or if we need to actually abort in some way if that occurs.

Powered by Google App Engine
This is Rietveld 408576698