History log of /frameworks/native/services/surfaceflinger/LayerRejecter.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
7bf247e2db180da661b18084d50e0b389686fc0c 18-May-2017 Robert Carr <racarr@google.com> SurfaceFlinger: setGeometryAppliesWithResize crop latching fixes.

The same sort of thing we had with setPosition...not sure why I didn't
realize we would need the fixes here too! In particular we need to ensure
the following scenarios work:

1. Additional calls to set(Final)Crop while in the setGeometryAppliesWithResize
state are eventually applied.
2. Additional calls to set(Final)Crop while in the setGeometryAppliesWithResize
state are not immediately applied.
3. In LayerRejector.cpp we have to be sure we are not just latching a buffer
at the old size, which we still allow. This is the correct time to latch
the transparentRegion as it is content dependent, but doesn't represent
a size changing.

The difference between this and the original CL which was reverted has to do with
point 3. The original CL tried to solve point 3 by moving the latching logic from
the LayerRejecter in to Layer::doTransaction. However, in general doTransaction
will not be called in between Latching the buffer and drawing the frame, so this
introduced errors. The new test "FinalCropLatchingBufferOldSize" encapsulates this.

Bug: 37621737
Bug: 37531386
Test: Included in Transaction_test.cpp
Change-Id: I14bd09d01ac6b85895caa1b707d6fa7dac962074
/frameworks/native/services/surfaceflinger/LayerRejecter.cpp
a3ed032256c475ce13c52b0261da6a5e2ffa77be 16-May-2017 Rob Carr <racarr@google.com> Revert "SurfaceFlinger: setGeometryAppliesWithResize crop latching fixes."

This reverts commit 1e079c2804edfae77925150280fe79418e58750b.

Bug: 38331032
Change-Id: Ib703b7b80a940550487a80d8ad62947e4becae93
/frameworks/native/services/surfaceflinger/LayerRejecter.cpp
1e079c2804edfae77925150280fe79418e58750b 09-May-2017 Robert Carr <racarr@google.com> SurfaceFlinger: setGeometryAppliesWithResize crop latching fixes.

The same sort of thing we had with setPosition...not sure why I didn't
realize we would need the fixes here too! In particular we need to ensure
the following scenarios work:

1. Additional calls to set(Final)Crop while in the setGeometryAppliesWithResize
state are eventually applied.
2. Additional calls to set(Final)Crop while in the setGeometryAppliesWithResize
state are not immediately applied.
3. When we latch the buffer completing the resize...current hasn't been swapped
to drawing...which means our location in LayerRejector.cpp was the wrong
place to update the crop. This raises questions about whether the
Transparent region latching works.

Bug: 37531386
Test: Included in Transaction_test.
Change-Id: I5140d44fd5e591a4afe5bddc201db45f7bcb5674
/frameworks/native/services/surfaceflinger/LayerRejecter.cpp
8d5227b8416b099c884429312daf2d60496fa484 16-Mar-2017 Robert Carr <racarr@google.com> Include finalCrop in setGeometryAppliesWithResize.

A refresher on this archaic function. Normally window crop and
position apply immediately. This is so the window manager can always
crop surfaces (e.g. while docked resizing) even if the app is lagging
behind. In some cases though the apps position or cropping may depend
on whether the resize has occured or not. For example when an app
gains shadows, we need to move expand the Surface and move it by a
negative offset for the content to remain in the same place. This
movement needs to be synchronized with the buffer latching for the
expansion.

We implemented setGeometryAppliesWithResize to take care of this. At
the time it wasn't clear if it was needed for finalCrop so we let it
be. Now that we are exclusively using final crop in the pinned stack
however it is required. The same way we have an issue with position
and shadows, we have an issue with expanding the crop rect (we may
have actually been cropping out part of a larger surface that is now
supposed to be shadows).

Also includes a test suite for setGeometryAppliesWithResize behavior
which was previously untested.

Bug: 35396882
Test: SurfaceFlinger_test
Change-Id: Ie4d32162eb21154496bb231161692d18341a1e1e
/frameworks/native/services/surfaceflinger/LayerRejecter.cpp
a9347647eca3101c014be902b713772de3977d87 14-Feb-2017 Mathias Agopian <mathias@google.com> Break a dependency of libui on libandroid

This was only a header dependency, but it still
created a circular dependency, which will cause
problems in another CL.

We fix this by creating a libarect static library
containing only that header. both libui and
libandroid now depend on it and reexport the
header.

We also make sure rect.h ends-up in the right
place.

Test: built and booted device
Bug: 35164655

Change-Id: Iba25b8b801b26b26ec1401c00caf367a06f197ca
/frameworks/native/services/surfaceflinger/LayerRejecter.cpp
7b1563a0e8e742315a16c9a7b27537dbcd13d09a 13-Oct-2016 Fabien Sanglard <sanglardf@google.com> Refactor surfacefinger Layer::latchBuffer

Take out Rejecter class declaration out of the method. This
increases readability and shortens latchBuffer method by 200 lines.

Change-Id: I8b07c63f8ed6408e68d5696d0666e65a3b14bd4c
/frameworks/native/services/surfaceflinger/LayerRejecter.cpp