Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 5dc3f284 authored by Robert Carr's avatar Robert Carr Committed by Rob Carr
Browse files

Remove reuse of pending deferred transactions. 

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
parent 735b9eca

services/core/java/com/android/server/wm/WindowStateAnimator.java

+0 −26
Original line number Diff line number Diff line
@@ -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

services/core/java/com/android/server/wm/WindowSurfacePlacer.java

+0 −4
Original line number Diff line number Diff line
@@ -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) {