summaryrefslogtreecommitdiffstats
path: root/cc/scheduler_state_machine.h
Commit message (Collapse)AuthorAgeFilesLines
* Use message passing for BeginFrameAndCommitState and clean up forced commit ↵jamesr@chromium.org2012-11-141-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | logic This passes the BeginFrameAndCommitState struct along with messages instead of relying on (racy) shared memory and slightly simplifies the forced commit logic. This logic is for compositeAndReadback() and is trying to go through the normal commit flow while the main thread is blocked. The normal commit flow is this: 1.) Main thread posts task to compositor thread requesting commit 2.) Compositor thread receives notification, after some delay posts task to main to run the beginFrame logic 3.) Main thread runs the beginFrameTask, posts a blocking task to compositor thread 4.) With the main thread is blocked, compositor thread runs the beginFrameComplete task and signals the main thread to get on with life 5.) Compositor thread waits for an opportunity to draw (vsync) then goes back to the initial state. compositeAndReadback() requires that we run through the whole flow up through 5 without yielding the main thread at all. However, while it's doing this there may very well be another beginFrame task pending on the main thread's message queue. When this task does eventually run it needs to have a valid BFAC state and the reply has to be expected on the compositor side. This patch always passes the BFAC state on the beginFrame task and uses a null BFAC state for compositeAndReadback-forced beginFrame()s. This means when we do a compositeAndReadback we won't "see" state that has updated only on the compositor thread, but that's fine since we'll apply that state once we process the beginFrame task later on and BFAC state addition is additive. The tricky bit from the compositor side is keeping track of whether there's a pending beginFrame message after going through the forced commit flow. To keep track of this I've added SchedulerStateMachine::m_expectImmediateBeginFrame that keeps the scheduler in a state that expects a beginFrameComplete after finishing the readback. Typical flow: 1.) Main thread enters compositeAndReadback(), posts a blocking forceBeginFrame task to compositor thread 2.) Compositor thread posts beginFrame task to main thread 3.) Compositor thread processes forceBeginFrame task, sets scheduler bits, signals main thread to continue 4.) Main thread runs beginFrame(NULL), posts beginFrameComplete to compositor thread 5.) Compositor thread processes beginFrameComplete, runs through state machine up to draw and then goes back to waiting for a reply to the beginFrame it posted in step (2) 6.) Main thread issues sync readback, finishes compositeAndReadback() 7.) Main thread processes beginFrame message posted in (2), posts reply 8.) Profit! Note that steps (2) and (3) can happen in any order. BUG=158747 Review URL: https://chromiumcodereview.appspot.com/11362054 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@167537 0039d316-1c4b-4281-b951-d872f2087c98
* cc: Fix header include guards of our header files.tfarina@chromium.org2012-11-051-3/+3
| | | | | | | | | | | | | Fixed with a hacky python script :/ BUG=144576,144577 TEST=$ cpplint.py cc/*.h 2>&1 | grep header_guard. And verified it doesn't complain. R=enne@chromium.org,jamesr@chromium.org Review URL: https://chromiumcodereview.appspot.com/11368063 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@165895 0039d316-1c4b-4281-b951-d872f2087c98
* Make cc a componentpiman@chromium.org2012-11-021-1/+2
| | | | | | | | BUG=154052 Review URL: https://codereview.chromium.org/11365025 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@165748 0039d316-1c4b-4281-b951-d872f2087c98
* cc: Rename cc classes and members to match filenamesenne@chromium.org2012-10-221-4/+4
| | | | | | | | | | | Fixed reland of https://chromiumcodereview.appspot.com/11189043/ TBR=jam@chromium.org,jamesr@chromium.org BUG=155413 Review URL: https://codereview.chromium.org/11231054 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@163429 0039d316-1c4b-4281-b951-d872f2087c98
* Revert "cc: Rename cc classes and members to match filenames"enne@chromium.org2012-10-191-4/+4
| | | | | | This reverts commit 184fac5add06d5f4670fa6be4a4d3b39232d51bb. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@163059 0039d316-1c4b-4281-b951-d872f2087c98
* cc: Rename cc classes and members to match filenamesenne@chromium.org2012-10-191-4/+4
| | | | | | | | BUG=155413 Review URL: https://codereview.chromium.org/11189043 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@163052 0039d316-1c4b-4281-b951-d872f2087c98
* [cc] Rename all cc/ filenames to Chromium styleenne@chromium.org2012-10-121-1/+159
| | | | | | | | BUG=155413 Review URL: https://codereview.chromium.org/11122003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@161671 0039d316-1c4b-4281-b951-d872f2087c98
* [cc] Land preliminary empty headers for libcc renamesenne@chromium.org2012-10-121-0/+3
Landing empty headers first will prevent gyp conflicts later. BUG=155413 Review URL: https://chromiumcodereview.appspot.com/11116002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@161526 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-02-08 04:16:44 +0000