[DL] Refactor API between DisplayLockContext and budget.
Instead of computing deadlines and lifecycle counts relative to last observation, inject the latest lifecycle count of the releveant frame generator (LocalFrameView) and the actual start time of the lifecycle. This simplifies the code somewhat, improves dependencies, and has two concrete benefits: 1. Uses the same deadline for all locks executed on the same frame. Previously each lock would compute its own deadline at the time WillStartLifecycleUpdate was called. 2. Allows skipping lifecycles if desired. e.g. if a lock is updating, but we decide not to doing anything for it for a given frame, we can skip it. This CL achieves benefit #2; benefit #1 is a possible future addition. Note that WillStartLifecycleUpdate is still required for all locks which are currently acquiring, updating or committing (but not quiesecent locks). The reason it's required is that there may be forced style or layout computations between lifecycles, and those end up clearing the dirty bits of the lifecycle. There needs to be a mechanism to re-set those dirty bits, and WillStartLifecycleUpdate is that mechanism. Bug: 968928 Change-Id: Ibe7e2c51631e7a93101563db41a444d01ae54162 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1642789 Commit-Queue: Chris Harrelson <chrishtr@chromium.org> Reviewed-by:vmpstr <vmpstr@chromium.org> Cr-Commit-Position: refs/heads/master@{#667273}
Showing
This diff is collapsed.
Please register or sign in to comment