Bug 71267 – [chromium] Slow down commit and draw rate based on visibility and draw completion

• Component: New Bugs
• Status: RESOLVED FIXED

[Nat Duca]

[chromium] Slow down commit and draw rate based on visibility and draw completion

[Nat Duca]

Created attachment 113133 [details]
Patch

[Nat Duca]

This patch does three things:
1. Removes the setNeedsRedraw that CCThreadProxy used to force after commit [since that is now inside the scheduler]
2. Does not let a new commit begin until the previous commit makes it onscreen.
2. Does not draw when invisible [and because of #2, does not begin a new commit when invisible]

Based on measurements, this should help stabilize frame rates and reduce overlap.

This depends on changing the handling of setVisible(false) from triggering a commit to something more situation-specific.

[James Robinson]

Comment on attachment 113133 [details]
Patch

Logic looks good but I'm not sure I understand the distinction between immediate state and member bools on CCSchedulerStateMachine. It feels a bit odd to push visible/not visible to the state machine on every nextAction() since it doesn't change very much - but I suspect there's some reason for the distinction other than frequency of change. Let's sync in person

[James Robinson]

BTW this merge conflicts with your STREQ change

[Nat Duca]

Created attachment 113375 [details]
Without ImmediateState

[James Robinson]

Comment on attachment 113375 [details]
Without ImmediateState

View in context: https://bugs.webkit.org/attachment.cgi?id=113375&action=review

R=me, one comment for you to think about and do what you think is best.

> Source/WebCore/platform/graphics/chromium/cc/CCScheduler.cpp:102
> +    // Adjust the state machine's visbility state to the proxy's visibility state
> +    m_stateMachine.setVisible(m_client->visible());

For your consideration: instead of pulling visible state from the client here, could the client push the visible state down when it changes to the scheduler? It's a little easier for me to reason about interactions when state tends to flow in one direction.

> Source/WebCore/platform/graphics/chromium/cc/CCSchedulerStateMachine.h:32
> +// The CCSched decides how to coordinates main thread activites

looks like you accidentally part of this comment

[Nat Duca]

(In reply to comment #6)
> For your consideration: instead of pulling visible state from the client here, could the client push the visible state down when it changes to the scheduler? It's a little easier for me to reason about interactions when state tends to flow in one direction.

Great point. Done. :)

[Nat Duca]

Committed r99100: <http://trac.webkit.org/changeset/99100>