Bug 84301 – [chromium] Add canBeginFrame state to CCSchedulerStateMachine to suppress initialization before our surface is available

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[James Robinson]

[chromium] Add canBeginFrame state to CCSchedulerStateMachine to suppress initialization before our surface is available

[James Robinson]

Created attachment 137802 [details]
Patch

[James Robinson]

This is the first part of the fixes for http://code.google.com/p/chromium/issues/detail?id=123356

[Nat Duca]

Comment on attachment 137802 [details]
Patch

Neat. LGTM.

[Adrienne Walker]

Comment on attachment 137802 [details]
Patch

How does canBeginFrame differ from canDraw? Is there ever a point where we want to begin a frame but can't draw?

[James Robinson]

(In reply to comment #4)
> (From update of attachment 137802 [details])
> How does canBeginFrame differ from canDraw? Is there ever a point where we want to begin a frame but can't draw?

canDraw doesn't block commit, this does.  The reason is that if the surface isn't ready yet, then the first makeContextCurrent() will fail so we can't even start the commit.  There are situations where we don't want to swap an actual frame but we can usefully do other things (do a commit, enqueue texture uploads, etc).

[Adrienne Walker]

Comment on attachment 137802 [details]
Patch

Ok, thanks for the explanation.  R=me.

[James Robinson]

Here's the rest with a longer explanation in the WebKit/chromium/ChangeLog: https://bugs.webkit.org/show_bug.cgi?id=84305

[James Robinson]

Committed r114599: <http://trac.webkit.org/changeset/114599>