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

Issue 11571049: cc: Make the scheduler compositeAndReadback flow not race with WAITING_FOR_FIRST_DRAW (Closed)

Created:
8 years ago by danakj
Modified:
8 years ago
Reviewers:
jamesr, nduca
CC:
chromium-reviews, cc-bugs_chromium.org, nduca, piman, backer
Visibility:
Public.

Description

cc: Make the scheduler compositeAndReadback flow not race with WAITING_FOR_FIRST_DRAW This fixes two problems in the compositeAndReadback flow. If you compositeAndReadback really fast after a commit and the scheduler is in WAITING_FOR_FIRST_DRAW but can't draw yet (e.g. inside a vsync), then: If canDraw() is false: - It would try to draw the previous commit and fail. drawing is, at this point, blocked until the next commit. So it would ScheduleActionBeginFrame. - Now it does the C&R beginFrame. This finishes and we enter WAITING_FOR_FIRST_DRAW. - We setNeedsRedraw(), which tries to draw, but canDraw() is false. So it would ScheduleActionBeginFrame. This moves us to FRAME_IN_PROGRESS. - Now we setNeedsForcedRedraw(), but we don't draw since we're now trying to commit. - Thus we leave the R&C without actually drawing, and with m_expectImmediateBeginFrame = true. - Now we set canDraw() true, and it draws and drops back to FRAME_IN_PROGRESS, and the unit test hangs waiting for the last commit to complete. If canDraw() is true: - Thread proxy does setNeedsForcedCommit which is supposed to produce a beginFrame. But because we're in WAITING_FOR_FIRST_DRAW, it would just try to draw the previous commit and fail (we're not blocked on drawing until the next commit so a beginFrame doesn't happen). - Thread proxy checks for a pending commit and sees the WAITING_FOR_FIRST_DRAW as a pending commit, so it signals the beginFrame to go. - Then it does the C&R beginFrame. This finishes and we enter WAITING_FOR_FIRST_DRAW. - We force a draw, which works and draws the R&C commit. It moves us to FRAME_IN_PROGRESS as expected. Now we've fixed the world. - We go to WAITING_FOR_FIRST_FORCED_DRAW which never does a beginFrame, so we don't to rely on inconsistent behaviour based on canDraw(). - Thread proxy does not mistake waiting for a draw as a commit in progress. So it waits until the previous commit's draw happens, and the beginFrame() is posted. BUG=165022 R=jamesr Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=173867

Patch Set 1 #

Patch Set 2 : #

Patch Set 3 : #

Patch Set 4 : #

Patch Set 5 : #

Patch Set 6 : indents #

Unified diffs Side-by-side diffs Delta from patch set Stats (+217 lines, -68 lines) Patch
M cc/layer_tree_host_unittest.cc View 1 2 3 4 2 chunks +82 lines, -3 lines 0 comments Download
M cc/scheduler_state_machine.h View 2 chunks +4 lines, -2 lines 0 comments Download
M cc/scheduler_state_machine.cc View 1 2 3 4 5 4 chunks +17 lines, -9 lines 0 comments Download
M cc/scheduler_state_machine_unittest.cc View 1 2 3 3 chunks +114 lines, -54 lines 0 comments Download

Messages

Total messages: 3 (0 generated)
jamesr
lgtm
8 years ago (2012-12-19 04:16:10 UTC) #1
danakj
8 years ago (2012-12-19 04:23:14 UTC) #2
nduca
8 years ago (2012-12-19 04:32:17 UTC) #3
Neat change. I likey.

Powered by Google App Engine
This is Rietveld 408576698