Bug 1451469 - Run deferred tasks on the controller thread. r?botond
Deferred tasks currently run as part of the sampling process, in
AdvanceAnimations. However, deferred tasks also sometimes need to acquire
the APZ tree lock for stuff. Acquiring the tree lock is not going to be
allowed on the render backend thread (which is the sampler thread when
WR is enabled), so we need to bump these tasks to another thread. The
controller thread is safe for this purpose.
MozReview-Commit-ID: AP3bnGF5UjL
--- a/gfx/layers/apz/src/AsyncPanZoomController.cpp
+++ b/gfx/layers/apz/src/AsyncPanZoomController.cpp
@@ -3662,24 +3662,21 @@ bool AsyncPanZoomController::AdvanceAnim
}
}
// Execute any deferred tasks queued up by mAnimation's Sample() (called by
// UpdateAnimation()). This needs to be done after the monitor is released
// since the tasks are allowed to call APZCTreeManager methods which can grab
// the tree lock.
for (uint32_t i = 0; i < deferredTasks.Length(); ++i) {
- deferredTasks[i]->Run();
- deferredTasks[i] = nullptr;
+ APZThreadUtils::RunOnControllerThread(deferredTasks[i].forget());
}
- // One of the deferred tasks may have started a new animation. In this case,
- // we want to ask the compositor to schedule a new composite.
- requestAnimationFrame |= (mAnimation != nullptr);
-
+ // If any of the deferred tasks starts a new animation, it will request a
+ // new composite directly, so we can just return requestAnimationFrame here.
return requestAnimationFrame;
}
ParentLayerPoint
AsyncPanZoomController::GetCurrentAsyncScrollOffset(AsyncTransformConsumer aMode) const
{
RecursiveMutexAutoLock lock(mRecursiveMutex);