diff options
author | Robert Carr <racarr@google.com> | 2021-02-08 13:11:46 -0800 |
---|---|---|
committer | Tiger Huang <tigerhuang@google.com> | 2021-03-11 00:14:17 +0800 |
commit | 932814a00eb19d51481f7d0fc34b1eba2967f241 (patch) | |
tree | 978464fd0f65de8d9279c689751a48e96b6bc761 /tools/aapt2/java/JavaClassGenerator_test.cpp | |
parent | 9a2ae3ed4c8afd286dd9bae8deec5cf77fc001f0 (diff) |
WindowState: Introduce applyWithNextDraw, port Seamless Rotation
While BLASTSyncEngine is a good primitive for syncing changes to
multiple window containers, it's complexity introduces constraints,
namely that only one BLASTSyncEngine sync may be active at a time (for
a given window container). As more and more parts of the WM wish to rely
on BLASTSync, this can create a difficult coordination problem. In this
CL we expose a per WindowState sync mechanism (applyWithNextDraw) which
can compose with BLASTSyncEngine transactions, and can be used by
multiple features simultaneously on a given WindowState.
This system works by maintaining a list of "DrawHandlers"
(Consumer<Transaction>), in each WindowState. At a high level, when
adding a draw handler we request the client to redraw, and when
we receive the Transaction containing the frame in finishDrawing
we invoke the handler, giving it a chance to append to the transaction
before it is applied or merged in to a higher level BLASTSyncEngine
transaction.
Next we port seamless rotation to this system. The concept is relatively
easy, the setup proceeds as before: In the same transaction we rotate
the display projection we create a SeamlessRotator to unrotate the apps
original orientation buffer. Seamless rotation requires us to remove
this transform when the app redraws, and this is trivially accomplished
with the applyWithNextDraw primitive.
Bug: 168505645
Bug: 181424834
Test: Existing tests pass
Change-Id: Ie84d99e58b8d0efedbedab0ea48a441826e3a7bf
Diffstat (limited to 'tools/aapt2/java/JavaClassGenerator_test.cpp')
0 files changed, 0 insertions, 0 deletions