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
|