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

Skip to content
Commit 123ca798 authored by Evan Rosky's avatar Evan Rosky
Browse files

Convert BLASTSyncEngine to a polling mechanism

SyncEngine's requirements are getting more demanding as it is
used in transitions as-well as more-complicated interractions
in Shell. In order to meet the requirements, this converts
BLASTSyncEngine to work mostly by polling during surface-placement.

The previous set-up was already gated on surface-placement, so
there shouldn't be any additional latency.

There is now only one SyncEngine (instead of many) and it manages
SyncGroups which must not overlap. Whenever a container is added
to a sync group, the SyncEngine will monitor the subtree rooted at
that container. When a child receives finishDrawing: instead of
immediately reporting to the engine, it simply remembers that it
is now READY for sync. On each surface-placement pass, SyncEngine
will check the subtrees to see if everything is finished syncing.

This enabled the following:
- Now handles visibility changes and new children (since it is
  always checking the full subtree). This is needed to deal with
  opening transitions.
- Doesn't wait for occluded siblings. This is needed to deal with
  starting windows.
- Handles parenting changes: immediately applies sync transactions
  on subtrees exiting the sync-group, requests updates/waits
  on subtrees entering, and re-requests updates for subtrees moving
  within the group.
- Includes removals in sync transaction

Bug: 161710818
Test: SyncEngineTests
Change-Id: Ic3fdc091d5656b3eaea45bce449e098ee9d2aabb
parent 97d89af9
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment