[chromium] Slow down commit and draw rate based on visibility and draw completion
Created attachment 113133 [details] Patch
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.
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
BTW this merge conflicts with your STREQ change
Created attachment 113375 [details] Without ImmediateState
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
(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. :)
Committed r99100: <http://trac.webkit.org/changeset/99100>