Android/frameworks_base
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Remove reuse of pending deferred transactions.

Browse Source 
Only defer transactions originating from repositionChild. There is
no guarantee the frame we are suggested to synchronize to will ever
arrive and synchronizing WM originated transactions to this can
interfere with implementation of system policy. Anyway this code
originally was fixing a case where transactions pushed by pulling
down the notification shade, would interrupt animating SurfaceView's
by pushing an undeferred transaction for those SurfaceView's. This
doesn't seem to be occuring anymore even without this code. Furthermore
even if it was occuring, we should prevent transactions from pushing
updates for Surfaces where nothing has really changed, rather than
attempt to chain the deferred transactions.

Bug: 31293950
Bug: 27098060
Bug: 28858420
Change-Id: Ifb83fe78bb4e7d18376e53a743709648aa1e03bc
This commit is contained in:
Robert Carr
2016-09-08 12:56:42 -07:00
committed by Rob Carr
parent 735b9eca0f
commit 5dc3f284bd
2 changed files with 0 additions and 30 deletions
Download Patch File Download Diff File Expand all files Collapse all files

26
services/core/java/com/android/server/wm/WindowStateAnimator.java
View File

@@ -228,8 +228,6 @@ class WindowStateAnimator {
int mAttrType;
static final long PENDING_TRANSACTION_FINISH_WAIT_TIME = 100;
long mDeferTransactionUntilFrame = -1;
long mDeferTransactionTime = -1;
boolean mForceScaleUntilResize;
@@ -2055,35 +2053,11 @@ class WindowStateAnimator {
if (!mWin.isChildWindow()) {
return;
}
mDeferTransactionUntilFrame = frameNumber;
mDeferTransactionTime = System.currentTimeMillis();
mSurfaceController.deferTransactionUntil(
mWin.mAttachedWindow.mWinAnimator.mSurfaceController.getHandle(),
frameNumber);
}
// Defer the current transaction to the frame number of the last saved transaction.
// We do this to avoid shooting through an unsynchronized transaction while something is
// pending. This is generally fine, as either we will get in on the synchronization,
// or SurfaceFlinger will see that the frame has already occured. The only
// potential problem is in frame number resets so we reset things with a timeout
// every so often to be careful.
void deferToPendingTransaction() {
if (mDeferTransactionUntilFrame < 0) {
return;
}
long time = System.currentTimeMillis();
if (time > mDeferTransactionTime + PENDING_TRANSACTION_FINISH_WAIT_TIME) {
mDeferTransactionTime = -1;
mDeferTransactionUntilFrame = -1;
} else if (mWin.mAttachedWindow != null &&
mWin.mAttachedWindow.mWinAnimator.hasSurface()) {
mSurfaceController.deferTransactionUntil(
mWin.mAttachedWindow.mWinAnimator.mSurfaceController.getHandle(),
mDeferTransactionUntilFrame);
}
}
/**
* Sometimes we need to synchronize the first frame of animation with some external event.
* To achieve this, we prolong the start of the animation and keep producing the first frame of

4
services/core/java/com/android/server/wm/WindowSurfacePlacer.java
View File

@@ -742,10 +742,6 @@ class WindowSurfacePlacer {
// Moved from updateWindowsAndWallpaperLocked().
if (w.mHasSurface) {
// If we have recently synchronized a previous transaction for this
// window ensure we don't push through an unsynchronized one now.
winAnimator.deferToPendingTransaction();
// Take care of the window being ready to display.
final boolean committed = winAnimator.commitFinishDrawingLocked();
if (isDefaultDisplay && committed) {