summaryrefslogtreecommitdiffstats
path: root/cc/scheduler/scheduler.cc
Commit message (Collapse)AuthorAgeFilesLines
* cc: Add trace events for the Scheduler states.brianderson@chromium.org2013-08-211-4/+9
| | | | | | | | | | | | | | 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-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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-2/+2
| | | | | | | | | | | | | | | | | 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
* cc: Fix infinite BeginFrame that Scheduler causes.dongseong.hwang@intel.com2013-06-261-1/+2
| | | | | | | | | | | | | | | | | | | REGRESSION(r206955): Remove the chance to disable SetNeedsBeginFrame. r206955 made SetNeedsBeginFrame be called proactively, but the proactive condition mostly was true. This issue makes proactive_begin_frame_wanted condition more restrict. There are two changes. 1. Do not be proactive when invisible. 2. Do not be proactive when throttling frame production. This patch is mostly based on what Brian Anderson consults. BUG=253543 Review URL: https://chromiumcodereview.appspot.com/17587014 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@208662 0039d316-1c4b-4281-b951-d872f2087c98
* cc: Initialize Scheduler::safe_to_expect_begin_frame_brianderson@chromium.org2013-06-201-0/+1
| | | | | | | | | TBR=nduca, groby BUG=252036 Review URL: https://chromiumcodereview.appspot.com/17447008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@207630 0039d316-1c4b-4281-b951-d872f2087c98
* cc: Remove cc::Thread and cc::ThreadImpl.danakj@chromium.org2013-06-201-1/+0
| | | | | | | | | | | | | These classes are replaced by using base::SingleThreadTaskRunner directly. R=piman,jamesr BUG=251134 Depends on: https://codereview.chromium.org/17362002/ Review URL: https://chromiumcodereview.appspot.com/17114008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@207491 0039d316-1c4b-4281-b951-d872f2087c98
* cc: Add BeginFrameArgs brianderson@chromium.org2013-06-191-11/+12
| | | | | | | | | | | | 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-58/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | 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-68/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* cc: Emulate BeginFrame in OutputSurfaces that don't support it nativelybrianderson@chromium.org2013-06-131-57/+68
| | | | | | | | | | | | | | | | | | | | | 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-68/+57
| | | | | | | | | | | | | | | | | | | | | | | > 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-57/+68
| | | | | | | | | | | | | | | | | 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-12/+6
| | | | | | | | | | | | | | | | | | | | | 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/+4
| | | | | | | | | | | | 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-18/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* DelegatingRenderer: send frame on SwapBuffers instead of DrawFramepiman@chromium.org2013-05-081-0/+4
| | | | | | | | | | | | | | | | 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-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [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-7/+7
| | | | | | | | | | | | | | | | | | | | | 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-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | [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-7/+7
| | | | | | | | | | | | | | | | | 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/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Fix capitalization style in chromified files.danakj@chromium.org2013-03-251-5/+5
| | | | | | | | | | | | | | | | | Style-only change. Many already-chromified files missed a variable or function name here and there. This grabs (hopefully) all of them. For the record, I found these with: git gs '[^a-zA-Z0-9_>\."][a-jl-z]\+[A-Z][A-Za-z0-9_]*\($\|[ !=;,\.^&*)"]\)' R=enne BUG= Review URL: https://chromiumcodereview.appspot.com/12676029 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@190326 0039d316-1c4b-4281-b951-d872f2087c98
* cc: Chromify FrameRateControllerbrianderson@chromium.org2013-03-201-16/+16
| | | | | | | | | | | 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
* Delay resetting the frame rate controller count until we get a new surface.backer@chromium.org2013-03-191-1/+1
| | | | | | | | | | | | | | By defering the frame rate controller reset until we recreate an output surface, we don't have to reason about swaps that may be in flight on the lost context (i.e. we have swapped out renderers so no swap complete callbacks on previous surface will be called). BUG=196655 Review URL: https://chromiumcodereview.appspot.com/12541022 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@188923 0039d316-1c4b-4281-b951-d872f2087c98
* Part 9 of cc/ directory shuffles: schedulerjamesr@chromium.org2013-03-181-0/+202
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-03-27 18:03:42 +0000