summaryrefslogtreecommitdiffstats
path: root/cc/scheduler/scheduler.h
Commit message (Collapse)AuthorAgeFilesLines
* cc: Make PrepareToDraw return an enum for why it abortsenne@chromium.org2014-01-301-10/+1
| | | | | | | | | | This is mostly a cosmetic patch to change a boolean into an enum. BUG=335289 Review URL: https://codereview.chromium.org/131683005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@247869 0039d316-1c4b-4281-b951-d872f2087c98
* cc: add DevTools instrumentation for impl-side framescaseq@chromium.org2013-12-021-3/+7
| | | | | | | | | | | | | | | | This adds devtools_instrumentation::didBeginFrame() invoked from Scheduler::BeginImplFrame() and devtools_instrumentation::didCommitMainThreadFrame invoked from LayerTreeHost::FinishCommitOnImplThread(). We use the latter to associate impl-side frames with main thread ones on the DevTools side. Related blink-side patch: https://codereview.chromium.org/59793003/ BUG=305863 Review URL: https://codereview.chromium.org/60353002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@238150 0039d316-1c4b-4281-b951-d872f2087c98
* Kick ProcessScheduledActions while a commit is pendingjamesr@chromium.org2013-11-131-0/+2
| | | | | | | | | | | | | | | | | | | | | We can get into situations where the render compositor is at the pending swap limit but we won't get any swap acks until we allow a pending commit to complete. For example, on windows when using ubercompositor the browser's UI thread can be blocked on an NPAPI plugin (via HWND parenting) and the NPAPI plugin can be blocked on running a piece of javascript that is blocked on the render process main thread which is blocked on the commit finishing. When we're in this state, we need to continually ProcessScheduledActions() in order to process any pending uploads, etc, so the commit can complete and release the deadlock. This sort of thread dependency is rare, and polling is not the ideal behavior for framerate, so this sets up a repeating timer at 1/2 the expected framerate to make sure we don't block forever but usually use the normal BeginImplFrame mechanism to rate limit. The deadlock here is specifically: 1.) Render compositor's FrameRateController is at the swap limit 2.) Render compositor's frame is pending on the browser UI thread's message loop 3.) Browser UI thread is blocked on ::SetWindowPos(), which is synchronous on the thread owning the HWND (a windowed plugin in this case) 4.) NPAPI plugin's thread is blocked executing a synchronous call to its host 5.) Render process main thread is blocked waiting for its commit to complete 6.) Render process compositor thread has uploaded all the textures that ResourceUpdateController wants to upload per tick and is waiting for a frame to be produced before it uploads more textures This releases the deadlock by calling cc::Scheduler::ProcessScheduledActions() which calls cc::ThreadProxy::DidAnticipatedDrawTimeChange() which then calls cc::ResourceUpdateController::PerformMoreUpdates() with the new anticipated draw time. The ResourceUpdateController will eventually upload all of the textures pending in the commit and unblock the commit completing. BUG=317430 R=enne@chromium.org Review URL: https://codereview.chromium.org/66783005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@234728 0039d316-1c4b-4281-b951-d872f2087c98
* Scheduler: Switch from high to low latency mode if possible.dominikg@chromium.org2013-11-081-0/+5
| | | | | | | | | | | | | | | Detect if the renderer's impl thread is one frame behind the main thread (i.e. the main thread is in a high latency mode). If, based on our estimates, the main thread can produce a new tree before the impl thread's deadline, skip a BeginMainFrame to let the impl thread catch up and operate in low latency mode from then on. This feature is currently disabled by default. BUG=309648 Review URL: https://codereview.chromium.org/54913003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@233734 0039d316-1c4b-4281-b951-d872f2087c98
* cc: Don't ManageTiles twice in one frameenne@chromium.org2013-11-051-0/+1
| | | | | | | | | | | | | | | | | | | | Any external callers of ManageTiles should inform the Scheduler that ManageTiles happened so that (1) it can clear the "needs manage tiles" flag and (2) it can avoid doing a second ManageTiles on the same frame. Other than after commit, where ManageTiles needs to be called immediately in order to kick off new raster tasks (or determine that no raster tasks are required to activate the tree), ManageTiles just needs to be called periodically to keep the raster jobs working on the most important content. Delaying the periodic caller to prevent these bad frames with commits is a worthwhile tradeoff. R=brianderson@chromium.org BUG=314882 Review URL: https://codereview.chromium.org/45923005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@233111 0039d316-1c4b-4281-b951-d872f2087c98
* cc: Prioritize impl-thread drawing in scheduler in smoothness modeskyostil@chromium.org2013-10-221-0/+2
| | | | | | | | | | | | | | | When the compositor is in prefer smoothness mode, prioritize impl-thread draws over main thread frames and tree activations in the scheduler. This makes it less likely for us to drop frames during smoothness-triggering gestures such as flings and pinch-zooms. The tradeoff is that main thread updates will have higher latency in these modes. BUG=309630 Review URL: https://codereview.chromium.org/35013002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@230141 0039d316-1c4b-4281-b951-d872f2087c98
* Rename BeginFrame to BeginMainFrame and BeginImplFrame in cc::Scheduler.dominikg@chromium.org2013-10-211-15/+15
| | | | | | | | | | | | | | | | Second patch in a series to rename BeginFrame. This patch focuses on cc::Scheduler. In the scheduler, the term 'BeginFrame' is used for both the main thread and the impl thread. This can cause confusion if it's not obvious which one is being refered to. To clarify this, we rename BeginFrame to BeginMainFrame and BeginImplFrame, respectively. BUG=261765 Review URL: https://codereview.chromium.org/32343002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@229954 0039d316-1c4b-4281-b951-d872f2087c98
* CC: WeakPtrFactory should be the last member.dmichael@chromium.org2013-10-081-1/+2
| | | | | | | | BUG=303818 Review URL: https://codereview.chromium.org/26228003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@227578 0039d316-1c4b-4281-b951-d872f2087c98
* cc: Implement deadline scheduling disabled by defaultbrianderson@chromium.org2013-09-211-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds logic to the Scheduler to actually use the BeginFrame and deadline, but is not enabled by default on any platform yet. This will ensure emulation of old scheduler in the fallback path is sane. Emulation of the old path is implemented using an immediate deadline. SchedulerStateMachine::begin_frame_state has been added and can be in one of 4 states: Idle, InsideBeginFrame, DeadlinePending, or InsideDeadline. Notable restrictions of the states are: - We start a commit as soon after InsideBeginFrame as we can, since the BeginFrame will be coordinated with user input. (True on Android. Soon to be true on other platforms.) - We do not start a commit while Idle, in order to wait for the next batch of user input. - Draw and swap only occurs during the InsideDeadline state. The deadlines of the Browser and Renderer compositors can be nested in order to have a total draw latency of < 1 frame when starting off. If we can't hit 1 frame of latency consistently, we will fall back to a higher latency mode to increase throughput. TBR=enne@chromium.org BUG=243461 Review URL: https://chromiumcodereview.appspot.com/24070006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@224560 0039d316-1c4b-4281-b951-d872f2087c98
* cc: Always use SetNeedsBeginFrame to request the next BeginFramebrianderson@chromium.org2013-09-141-1/+0
| | | | | | | | | | | | | | | | This avoids relying on SwapBuffers to implicitly trigger the next BeginFrame. Only a single code path is used to request the next BeginFrame now: SetNeedsBeginFrame(true). This avoids issues where OutputSurface subclasses might not call OutputSurface::DidSwap() when they need to or when we early out a swap request and don't actually swap anything. BUG=289755 Review URL: https://chromiumcodereview.appspot.com/23498035 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@223218 0039d316-1c4b-4281-b951-d872f2087c98
* CC: Add a scheduled action for ManageTilesepenner@chromium.org2013-09-141-0/+11
| | | | | | | | | | | | | | | | | Other than commits, ManageTiles should be coalesced to happen on a semi-regular basis. This used to happen during draws, but this is not reliable as draws might not occur, nor we shouldn't force them to. This adds a scheduled action for ManagingTiles, and the ability to request this action, similar to requesting draws etc. BUG=264566 Review URL: https://chromiumcodereview.appspot.com/23495022 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@223182 0039d316-1c4b-4281-b951-d872f2087c98
* cc: Remove safe_to_expect_begin_frame workaroundbrianderson@chromium.org2013-09-121-3/+0
| | | | | | | | | | | | | | | The safe_to_expect_begin_frame workaround should no longer be needed because the scheduler properly only requests a BeginFrame when there is an output surface now. Removing the workaround will also help avoid race conditions where we receive overlapping BeginFrames with the deadline scheduler. BUG=289627 Review URL: https://chromiumcodereview.appspot.com/24019008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222729 0039d316-1c4b-4281-b951-d872f2087c98
* cc: Poll for state that triggers draws (synchronous compositor only)brianderson@chromium.org2013-09-121-0/+2
| | | | | | | | | | | | | | | | | This adds Scheduler::PollForAnticipatedDrawTriggers which is used by the synchronous compositor to avoid requesting BeginImplFrames when we might not actually draw new content, but still need to monitor state that might trigger a draw at vsync intervals. This can occur, for example, when the last swap used incomplete tiles (checkerboards or low-quality) or when a commit is aborted and we want to wait a vsync before starting the next commit. BUG=284810 Review URL: https://chromiumcodereview.appspot.com/23463014 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222711 0039d316-1c4b-4281-b951-d872f2087c98
* CC: Fix missing swap-used-incomplete-tile updatesepenner@chromium.org2013-09-071-1/+1
| | | | | | | | | | | | | | | | | | | When we early-out of a frame that has no damage, we didn't correctly detect if the frame had incomplete tiles. This patch only updates the flag if a swap actually occurs. To prevent this kind of bug in the future, this patch always sets the did-swap-use-incomplete-tile flag when it is known, rather than resetting it to false in one place and hoping it will always be set again correctly in all cases. The test times-out without this patch. BUG=284810 Review URL: https://chromiumcodereview.appspot.com/23686011 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@221891 0039d316-1c4b-4281-b951-d872f2087c98
* cc: Add readback and forced draw states to the Scheduler.brianderson@chromium.org2013-09-071-17/+12
| | | | | | | | | | | | | | | | | | | | Readback doesn't have all its steps synchronized properly with impl side painting enabled. This patch prevents the readback commit from being swapped to screen and avoids using non-readback commits for readback by adding a SynchronousReadbackState. This patch also gives forced draws due to checkerboarding its own ForcedReadback state that behaves independently of readback. Previously readback and forced draws shared drawing mechanisms, but we want readbacks to occur ASAP while we want forced draws to occur inline with the normal frame scheduling. BUG=276082 Review URL: https://chromiumcodereview.appspot.com/23503003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@221854 0039d316-1c4b-4281-b951-d872f2087c98
* Avoid "ForTesting" presubmit warning when changing ThreadProxy.danakj@chromium.org2013-08-271-1/+1
| | | | | | | | | | | | | | | | | | | | | The ThreadProxy calls the scheduler to return a base::Value representation of the state machine. While the thread proxy wraps this call in a ForTesting method, presubmit warnings go off because the ThreadProxy calls a ForTesting() method on another class, and ThreadProxy is not test code. I don't think there is a strong reason to name it Scheduler::StateAsValueForTesting() anyways, we do AsValue() all over the place for tracing and it makes good sense to do so. There would be no reason that having another callsite than the ThreadProxy's ForTesting one would be wrong. R=enne@chromium.org BUG= Review URL: https://codereview.chromium.org/23456003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@219822 0039d316-1c4b-4281-b951-d872f2087c98
* cc: Control activation from the Schedulerbrianderson@chromium.org2013-08-271-2/+2
| | | | | | | | | | | | | | | | | | | This threads the NotifyReadyToActivate signal all the way to the Scheduler, so that the Scheduler is the final arbiter of when to actually activate. With this information, we are also able to change the ScheduledActionActivateIfPossible to just ScheduledActionActivate, which will help reduce the number of calls to ManageTiles. This also checks if ManageTiles is needed after a commit. If it is not needed, the pending tree is ready for activation immediately. BUG=269272 Review URL: https://chromiumcodereview.appspot.com/22926024 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@219714 0039d316-1c4b-4281-b951-d872f2087c98
* cc: Add trace events for the Scheduler states.brianderson@chromium.org2013-08-211-1/+3
| | | | | | | | | | | | | | With upcoming scheduler changes, it'll be easier to understand the scheduler if there's a tracing option for the scheduler state. Given how much state there is to trace, a new disabled-by-default tracing category is used called "cc.debug.scheduler". BUG=276637 Review URL: https://chromiumcodereview.appspot.com/22802018 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@218686 0039d316-1c4b-4281-b951-d872f2087c98
* cc: Allow the main thread to cancel commitsenne@chromium.org2013-07-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a new SetNeedsUpdateLayers that triggers the commit flow, but is abortable if update layers doesn't actually make any changes. This allows the main thread to abort a begin frame. This happens in the case of scroll updates from the compositor thread or invalidations. There was previously an abort begin frame call for when a visibility message and a begin frame message were posted simultaneously, but it incorrectly applied the scrolls and scales without informing the compositor thread that these had already been consumed. To fix this, the abort message passes back a boolean about whether or not the commit was aborted (and needed to be sent again) or was handled (and the scrolls and scales processed). To avoid a deluge of begin frames (in the commit sense) from the scheduler, the scheduler has been adjusted to wait until the next begin frame (in the vsync signal sense) so that these calls can be throttled. Otherwise, the scheduler will just keep trying to begin frame. R=brianderson@chromium.org, danakj@chromium.org BUG=256381 Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=213338 Review URL: https://chromiumcodereview.appspot.com/19106007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@214314 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 213338 "cc: Allow the main thread to cancel commits"jochen@chromium.org2013-07-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Broke WebViewInteractiveTest.EditCommandsNoMenu on Mac [1288:27139:0723/221703:FATAL:layer_impl.cc(286)] Check failed: TotalScrollOffset().y() <= max_scroll_offset_.y() (62 vs. 47) > cc: Allow the main thread to cancel commits > > Add a new SetNeedsUpdateLayers that triggers the commit flow, but is > abortable if update layers doesn't actually make any changes. This > allows the main thread to abort a begin frame. This happens in the case > of scroll updates from the compositor thread or invalidations. > > There was previously an abort begin frame call for when a visibility > message and a begin frame message were posted simultaneously, but it > incorrectly applied the scrolls and scales without informing the > compositor thread that these had already been consumed. To fix this, > the abort message passes back a boolean about whether or not the > commit was aborted (and needed to be sent again) or was handled > (and the scrolls and scales processed). > > To avoid a deluge of begin frames (in the commit sense) from the > scheduler, the scheduler has been adjusted to wait until the next begin > frame (in the vsync signal sense) so that these calls can be throttled. > Otherwise, the scheduler will just keep trying to begin frame. > > R=brianderson@chromium.org, danakj@chromium.org > BUG=256381 > > Review URL: https://chromiumcodereview.appspot.com/19106007 TBR=enne@chromium.org Review URL: https://codereview.chromium.org/19519019 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@213355 0039d316-1c4b-4281-b951-d872f2087c98
* cc: Allow the main thread to cancel commitsenne@chromium.org2013-07-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Add a new SetNeedsUpdateLayers that triggers the commit flow, but is abortable if update layers doesn't actually make any changes. This allows the main thread to abort a begin frame. This happens in the case of scroll updates from the compositor thread or invalidations. There was previously an abort begin frame call for when a visibility message and a begin frame message were posted simultaneously, but it incorrectly applied the scrolls and scales without informing the compositor thread that these had already been consumed. To fix this, the abort message passes back a boolean about whether or not the commit was aborted (and needed to be sent again) or was handled (and the scrolls and scales processed). To avoid a deluge of begin frames (in the commit sense) from the scheduler, the scheduler has been adjusted to wait until the next begin frame (in the vsync signal sense) so that these calls can be throttled. Otherwise, the scheduler will just keep trying to begin frame. R=brianderson@chromium.org, danakj@chromium.org BUG=256381 Review URL: https://chromiumcodereview.appspot.com/19106007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@213338 0039d316-1c4b-4281-b951-d872f2087c98
* cc: Limit number of raster tasks that can be scheduled.reveman@chromium.org2013-07-231-1/+1
| | | | | | | | | | | | | | | | | Adds a limit of 256 to the number of raster tasks that can be scheduled. 256 should be high enough to not cause unnecessary scheduling but gives us some insurance that we're not spending a huge amount of time scheduling one enormous set of tasks. This also includes a s/CheckForCompletedTileUploads/UpdateVisibleTiles/ cleanup. BUG=262335 Review URL: https://chromiumcodereview.appspot.com/19792006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@213004 0039d316-1c4b-4281-b951-d872f2087c98
* Estimate commit and activation durationajuma@chromium.org2013-07-131-0/+2
| | | | | | | | | | | | | This adds estimates for the duration between BeginFrame being sent to the main thread and a commit finshing on the impl thread, and the duration between a commit finishing on the impl thread and tree activation completing. BUG=243459 Review URL: https://chromiumcodereview.appspot.com/18341011 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@211575 0039d316-1c4b-4281-b951-d872f2087c98
* Use a direct include of time headers in cc/.avi@chromium.org2013-06-271-1/+1
| | | | | | | | | | BUG=254986 TEST=none TBR=ben@chromium.org Review URL: https://chromiumcodereview.appspot.com/18120002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@209027 0039d316-1c4b-4281-b951-d872f2087c98
* cc: Add BeginFrameArgs brianderson@chromium.org2013-06-191-3/+3
| | | | | | | | | | | | In addition to the frame_time, include a deadline and interval with BeginFrame. Values used are placeholders for now, but will be used in the near future. BUG=240945 Review URL: https://chromiumcodereview.appspot.com/17391006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@207166 0039d316-1c4b-4281-b951-d872f2087c98
* cc: Emulate BeginFrame in OutputSurfaces that don't support it nativelybrianderson@chromium.org2013-06-181-18/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | Relanding again. This time, the proactive SetNeedsBeginFrame is broken out explicitly with logic to workaround crbug 249806 and to avoid expensive redraws with the synchronous renderer. This includes two small fixes for the original version of this patch that broke software compositing and WebView. This will allow us to avoid having two different code paths in the Scheduler. It also allows us to more easily remove the VSyncTimeSource and FrameRateController from the Scheduler. This patch instantiates the FrameRateController inside of OutputSurface for now, but the FrameRateController could be removed in future patches. BUG=245920 BUG=243497 BUG=249806 TBR=nduca@chromium.org,sievers@chromium.org,kbr@chromium.org Review URL: https://chromiumcodereview.appspot.com/17353002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@206955 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 206020 "cc: Emulate BeginFrame in OutputSurfaces that don..."reveman@google.com2013-06-171-14/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is causing pre-rendered pages to not load on android: crbug.com/249806 > cc: Emulate BeginFrame in OutputSurfaces that don't support it natively > > This includes two small fixes for the original version of this > patch that broke software compositing and WebView. > > This will allow us to avoid having two different code paths > in the Scheduler. It also allows us to more easily remove the > VSyncTimeSource and FrameRateController from the Scheduler. > > This patch instantiates the FrameRateController inside of > OutputSurface for now, but the FrameRateController could be > removed in future patches. > > BUG=245920 > BUG=243497 > TBR=nduca@chromium.org,sievers@chromium.org,kbr@chromium.org > > Review URL: https://chromiumcodereview.appspot.com/16833003 TBR=brianderson@chromium.org Review URL: https://codereview.chromium.org/17204002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@206655 0039d316-1c4b-4281-b951-d872f2087c98
* Estimate draw duration in SchedulerClientajuma@chromium.org2013-06-161-0/+1
| | | | | | | | | | | | | | | | This adds a DrawDurationEstimate method to SchedulerClient. The implementation of this method (in ThreadProxy) produces an estimate based on recent draw times. This also adds UMA stats measuring the duration of each draw and the amount by which this duration is underestimated or overestimated. BUG=243459 Review URL: https://chromiumcodereview.appspot.com/16574002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@206624 0039d316-1c4b-4281-b951-d872f2087c98
* cc: Emulate BeginFrame in OutputSurfaces that don't support it nativelybrianderson@chromium.org2013-06-131-18/+14
| | | | | | | | | | | | | | | | | | | | | This includes two small fixes for the original version of this patch that broke software compositing and WebView. This will allow us to avoid having two different code paths in the Scheduler. It also allows us to more easily remove the VSyncTimeSource and FrameRateController from the Scheduler. This patch instantiates the FrameRateController inside of OutputSurface for now, but the FrameRateController could be removed in future patches. BUG=245920 BUG=243497 TBR=nduca@chromium.org,sievers@chromium.org,kbr@chromium.org Review URL: https://chromiumcodereview.appspot.com/16833003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@206020 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 205750 "cc: Emulate BeginFrame in OutputSurfaces that don..."skaslev@chromium.org2013-06-121-14/+18
| | | | | | | | | | | | | | | | | | | | | | | > cc: Emulate BeginFrame in OutputSurfaces that don't support it natively > > This will allow us to avoid having two different code paths > in the Scheduler. It also allows us to more easily remove the > VSyncTimeSource and FrameRateController from the Scheduler. > > This patch instantiates the FrameRateController inside of > OutputSurface for now, but the FrameRateController could be > removed in future patches. > > BUG=245920 > BUG=243497 > > Review URL: https://chromiumcodereview.appspot.com/15836005 TBR=brianderson@chromium.org Review URL: https://codereview.chromium.org/16679010 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@205838 0039d316-1c4b-4281-b951-d872f2087c98
* cc: Emulate BeginFrame in OutputSurfaces that don't support it nativelybrianderson@chromium.org2013-06-121-18/+14
| | | | | | | | | | | | | | | | | This will allow us to avoid having two different code paths in the Scheduler. It also allows us to more easily remove the VSyncTimeSource and FrameRateController from the Scheduler. This patch instantiates the FrameRateController inside of OutputSurface for now, but the FrameRateController could be removed in future patches. BUG=245920 BUG=243497 Review URL: https://chromiumcodereview.appspot.com/15836005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@205750 0039d316-1c4b-4281-b951-d872f2087c98
* Unified OutputSurface::SwapBuffers.aelias@chromium.org2013-06-111-2/+0
| | | | | | | | | | | | | | | | | | | | | This patch introduces a hard contract that CC will always call OutputSurface::SwapBuffers(), and OutputSurface will always respond with OutputSurfaceClient::OnSwapBuffersComplete(), in all rendering modes. I deleted the methods SendFrameToParentCompositor, PostSubBuffer, and OnSendFrameToParentCompositorAck, subsuming them into SwapBuffers. I also deleted all the settings and capabilities specifying which variant needed to be called. This should be a no-op for all graphics modes except for Android WebView, where it has the benefits of ensuring OnSwapBuffersComplete is called and that CompositorFrameMetadata is available even though no parent compositor exists. NOTRY=true BUG=237006 Review URL: https://chromiumcodereview.appspot.com/16304003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@205501 0039d316-1c4b-4281-b951-d872f2087c98
* cc::OutputSurfaceClient::DeferredInitializeboliu@chromium.org2013-06-071-0/+1
| | | | | | | | | | | | SynchronousCompositorOutputSurface first starts in software only mode, then cc::OutputSurfaceClient::InitializeForGL is called to initialize the GL parts. BUG=230197 Review URL: https://chromiumcodereview.appspot.com/14772021 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@204771 0039d316-1c4b-4281-b951-d872f2087c98
* cc: Rename VSync to BeginFramebrianderson@chromium.org2013-05-231-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We are replacing hard vsync scheduling with BeginFrame+deadline intervals. This patch removes references to vsync in CC where it will no longer make sense. (One exception is cc::VSyncTimeSource, which will be removed in future patches to be incorporated into the scheduler itself.) Additionally, BeginFrames are clarified with suffixes whenever context is not enough and existing identifiers associated with BeginFrame when it no longer makes sense are renamed. A summary of the important renames are as follows: Browser Side Renames: COutputSurface::EnableVSyncNotification -> SetNeedsBeginFrame COutputSurface::OnDidVSync -> OnBeginFrame ViewHostMsg_SetVSyncNotificationEnabled -> ViewHostMsg_SetNeedsBeginFrame ViewMsg_DidVSync -> ViewMsg_BeginFrame Impl Side Renames: LTHI::EnableVSyncNotification -> SetNeedsBeginFrame LTHI::DidVSync -> BeginFrame LTHI::DidRecieveLastInputEventForVSync -> DidReceiveLastInputEventForBeginFrame Main+Impl Side Renames: LTHIClient::DidVSync -> BeginFrameOnImplThread LTHIClient::DidRecieveLastInputEventForVSync -> DidReceiveLastInputEventForBeginFrameOnImplThread TProxy::BeginFrame -> BeginFrameOnMainThread TProxy::ForceBeginFrameOnImplThread -> ForceCommitOnImplThread TProxy::BeginFrameCompleteOnImplThread -> StartCommitOnImplThread Scheduler::BeginFrameComplete -> FinishCommit Scheduler::BeginFrameAborted -> BeginFrameAbortedByMainThread Scheduler::LastVsyncTime -> LastBeginFrameOnImplThreadTime Scheduler::VSyncTick -> BeginFrame SchedulerSM::VSyncCallbackNeeded -> BeginFrameNeededByImplThread SchedulerSM::ACTION_BEGIN_FRAME -> ACTION_SEND_BEGIN_FRAME_TO_MAIN_THREAD FRC::DidBeginFrame -> DidSwapBuffers FRC::DidFinishFrame -> DidSwapBuffersComplete Random Renames: LTSettings::render_vsync_enabled -> throttle_frame_production LTSettings::render_vsync_notification_enabled -> render_parent_drives_begin_frame LTSettings::synchronously_disable_vsync -> using_synchronous_renderer_compositor RenderWidget::SynchronouslyDisableVSync -> UsingSynchronousRendererCompositor BUG=240945 Review URL: https://chromiumcodereview.appspot.com/15058004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@201739 0039d316-1c4b-4281-b951-d872f2087c98
* cc: Dump the scheduler's state when an unexpected action occurs.danakj@chromium.org2013-05-221-0/+4
| | | | | | | | | R=jamesr@chromium.org BUG= Review URL: https://codereview.chromium.org/15740013 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@201601 0039d316-1c4b-4281-b951-d872f2087c98
* DelegatingRenderer: send frame on SwapBuffers instead of DrawFramepiman@chromium.org2013-05-081-0/+1
| | | | | | | | | | | | | | | | CompositeAndReadback, though not implemented, should stay consistent. If we send the frame on DrawFrame, we will get an Ack from the browser, even though the frame rate controller doesn't expect one in that case. If that happens, num_frames_pending_ becomes negative and the frame rate throttling doesn't work any more, causing bad frames. Instead, be consistent with GLRenderer and send the frame on SwapBuffers. BUG=123444 TEST=LayerTreeHostTestNumFramesPending Review URL: https://chromiumcodereview.appspot.com/14941005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@198913 0039d316-1c4b-4281-b951-d872f2087c98
* Merge cc initialization pathsboliu@chromium.org2013-05-011-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | Code path between first initialization and recreate on context lost are merged. Do this by changing the first initialization behavior to match recreate. Now both are kicked off by the scheduler and blocks the main thread on the impl thread. The scheduler is started in output surface lost state and immediately schedules recreation. This means the first initialization in thread mode is no longer synchronous. BUG=233664, 230197 This has been tried many many times. NOTRY=true Reverted twice due to breaking WebGLInfobarTest: Committed in r196480. Reverted in r196509. Committed in r196708. Reverted in r196790. Fix for WebGLInfobarTest landed in r197235. WebViewTest.Shim became flaky on chromeos but was already flaky without this. Disabled it in r197497. Review URL: https://chromiumcodereview.appspot.com/12544032 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@197550 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 196708 "Merge cc initialization paths"nick@chromium.org2013-04-261-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [Reason for revert: WebGLInfobarTest.ContextLossInfobarReload was failing on the Linux Tests bot with high probability] > Merge cc initialization paths > > Code path between first initialization and recreate on context > lost are merged. Do this by changing the first initialization > behavior to match recreate. Now both are kicked off by the > scheduler and blocks the main thread on the impl thread. > > The scheduler is started in output surface lost state and > immediately schedules recreation. This means the first > initialization is no longer synchronous. > > BUG=233664, 230197 > > First commited in r196480. Reverted in r196509 due to exposing > WebGLInfobarTest that should never have passed on asan. Disable > them on asan: https://codereview.chromium.org/14499007/ > > Review URL: https://chromiumcodereview.appspot.com/12544032 TBR=boliu@chromium.org Review URL: https://codereview.chromium.org/14386008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@196790 0039d316-1c4b-4281-b951-d872f2087c98
* Merge cc initialization pathsboliu@chromium.org2013-04-261-3/+6
| | | | | | | | | | | | | | | | | | | | | Code path between first initialization and recreate on context lost are merged. Do this by changing the first initialization behavior to match recreate. Now both are kicked off by the scheduler and blocks the main thread on the impl thread. The scheduler is started in output surface lost state and immediately schedules recreation. This means the first initialization is no longer synchronous. BUG=233664, 230197 First commited in r196480. Reverted in r196509 due to exposing WebGLInfobarTest that should never have passed on asan. Disable them on asan: https://codereview.chromium.org/14499007/ Review URL: https://chromiumcodereview.appspot.com/12544032 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@196708 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 196480 "Merge cc initialization paths"nick@chromium.org2013-04-251-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | [Reason for revert: causing failures in the following tests: WebGLInfobarTest.ContextLossRaisesInfobar on Linux ASAN WebGLInfobarTest.ContextLossInfobarReload on Linux ASAN WebGLInfobarTest.ContextLossInfobarReload timeouts on Linux release] > Merge cc initialization paths > > Code path between first initialization and recreate on context > lost are merged. Do this by changing the first initialization > behavior to match recreate. Now both are kicked off by the > scheduler and blocks the main thread on the impl thread. > > The scheduler is started in output surface lost state and > immediately schedules recreation. This means the first > initialization is no longer synchronous. > > BUG=233664, 230197 > > Review URL: https://chromiumcodereview.appspot.com/12544032 TBR=boliu@chromium.org Review URL: https://codereview.chromium.org/14238033 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@196509 0039d316-1c4b-4281-b951-d872f2087c98
* Merge cc initialization pathsboliu@chromium.org2013-04-251-3/+6
| | | | | | | | | | | | | | | | | Code path between first initialization and recreate on context lost are merged. Do this by changing the first initialization behavior to match recreate. Now both are kicked off by the scheduler and blocks the main thread on the impl thread. The scheduler is started in output surface lost state and immediately schedules recreation. This means the first initialization is no longer synchronous. BUG=233664, 230197 Review URL: https://chromiumcodereview.appspot.com/12544032 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@196480 0039d316-1c4b-4281-b951-d872f2087c98
* cc: Make animations tick regardless of drawing.danakj@chromium.org2013-04-061-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The compositor should tick and finish animations even if it is not drawing anything. It can not draw for various reasons: 1) The tab is backgrounded. 2) CanDraw() is false for any of its reasons. 3) PrepareToDraw() fails due to checkerboarding. 4) There is no damage on the screen to draw. Currently the problems are: - When backgrounded, the animations are ticked but their states are not updated. - When CanDraw() is false, we don't draw, and animations just stop ticking. - If we stop drawing when we damage the screen, we tick animations, but don't update animation state since this happens in DrawLayers(). To solve these problems, I've moved the animation control more explicitly out of LayerTreeHostImpl. The proxy already calls Animate(). Now it will also call UpdateAnimationState(). It always does this after calling Animate() regardless if drawing or not. Secondly, the missing UpdateAnimationState() call is added to the OnTimerTick for background animation ticking. We enable background ticking only when we change visibility, currently. But when CanDraw() is false, we don't draw and thus don't tick animations. So instead we add to LayerTreeHostImpl a UpdateBackgroundAnimateTicking() method. We call this always after calling Animate() since that can remove animations - it's something Animate() used to do. And we also call this: a) After a commit - this could add new animations, or change visibility. b) After changing CanDraw()'s state. However, when PrepareToDraw() is false, we do not want to start new animations so we let animations finish without starting new ones. This is verified by the LayerTreeHostAnimationTestCheckerboardDoesntStartAnimations test. This is covered by adding single-thread mode to all the animation unit tests (except those that call SetNeedsAnimate() which is not legal in single thread mode). Also by new tests: LayerTreeHostAnimationTestRunAnimationWhenNotCanDraw.RunSingleThread LayerTreeHostAnimationTestRunAnimationWhenNotCanDraw.RunMultiThread LayerTreeHostAnimationTestRunAnimationWhenNotVisible.RunSingleThread LayerTreeHostAnimationTestRunAnimationWhenNotVisible.RunMultiThread LayerTreeHostAnimationTestCheckerboardDoesntStartAnimations.RunMultiThread Added scheduler tests: SchedulerStateMachineTest.ReportIfNotDrawing SchedulerStateMachineTest.ReportIfNotDrawingFromAcquiredTextures R=ajuma@chromium.org BUG=222915 Review URL: https://chromiumcodereview.appspot.com/13613003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@192671 0039d316-1c4b-4281-b951-d872f2087c98
* cc: Chromify FrameRateControllerbrianderson@chromium.org2013-03-201-1/+1
| | | | | | | | | | | Style-only change. BUG=144577 Review URL: https://chromiumcodereview.appspot.com/12922002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@189181 0039d316-1c4b-4281-b951-d872f2087c98
* Part 9 of cc/ directory shuffles: schedulerjamesr@chromium.org2013-03-181-0/+127
Continuation of https://src.chromium.org/viewvc/chrome?view=rev&revision=188681 BUG=190824 TBR=enne@chromium.org Review URL: https://codereview.chromium.org/12471008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@188697 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-02-12 06:27:00 +0000