| Age | Commit message (Collapse) | Author |
|---|
|
In some conditions of scheduling delays, Choreographer may
synthetically advance the indented vsync time. In that case we can't
send a vsync id since there is no one that corresponds to that time.
Test: TBD
Bug: 191840734
Change-Id: I7b2754d5dcb0a3f5fd6cda00a3a2469041116f67
|
|
- Use GPU finish time as well as actual deadline to determine jank
rate.
- Use dynamic interval to adjust for 60/90hz switching
- Move frame metrics reporting into JankTracker to adjust the
deadline communicated to the app when in stuffing scenario.
- Adjust double-stuffing detection to be a bit more readable.
Test: GraphicsStatsValidationTest.java
Test: adb shell dumpsys gfxinfo
Test: FrameMetricsListenerTest
Test: Log output of FrameMetricsObserver
Bug: 169858044
Change-Id: I3a6b8ed163e2cf9cf2b67667110340ebe35f98a1
|
|
Pass the frame deadline calculated by SF to Choreographer so
hwui would be able to improve its stats by knowing if a frame is
likely to be late.
Bug: 169858174
Test: manual
Change-Id: Ib9fd93638b54f08d8dc72fa6b023e2dd7c276dc7
|
|
Add plumbing to get shared timeline data from Surface Flinger to HWUI
and back.
Bug: 162890382
Bug: 162888881
Bug: 162890407
Test: manual using ALOG messages in SF
Change-Id: I85c5eb56d2fa933889518854e7b79b1e65e29af3
|
|
Using SYSTEM_TIME_MONOTONIC works for Android (where it translates to
CLOCK_MONOTONIC) and host targets, while CLOCK_MONOTONIC is not defined
on macOS.
Bug: 117921091
Test: existing tests should pass
Change-Id: I1fad472881830fb0701a320cf37319e083932ad4
|
|
Test: No code changes, just ran through clang-format
Change-Id: Id23aa4ec7eebc0446fe3a30260f33e7fd455bb8c
|
|
Fixes: 29072773
By using computeFrameTime AnimationContext would
potentially end up modifying the latest vsync if
a very-slow frame was received from the UI thread.
This could potentially desync animations that were
RT & UI thread 'synchronized', but more significantly
it would confuse the swap chain which tries to only
draw one frame per vsync causing unneccessary frame
drops.
Change-Id: Ibd2ec3157ce32fee1eec8d56837c45a35e622895
|
|
Is a bit naive, perhaps overly aggressive, but sorta works
Change-Id: I01a774e00dbe681439c02557d9728ae43c45ce50
|
|
Bug: 18226391
The issue occurs as a result of a dispatchFrame itself
taking longer than 12ms, the alloted budget. The result
is that a vsync request (which occured at the end) would
miss the vsync that occured 1ms prior to the end of the frame.
As a result it would end up waiting for the following vsync,
essentially dropping to 30fps even though 60 could have been
sustained.
Fix this with a few tweaks.
First, adjust the UI thread's delay bias from (now + 4ms) to
(vsync + 4ms), this prevents RT animators from slowly drifting
if the vsync occurs mid-task.
Second, request a vsync preemptively prior to running callbacks.
This way if any callbacks needs the next vsync and it takes
"too long", we will catch that vsync.
Finally, fix an issue where the display event queue was always
drained & rejected at the end of a task loop. Instead, drain
and reject all stale vsyncs. This still prevents the issue of
both UI thread & RT thread trying to drive 2 frames in a single
pulse, but also allows RT to notice that it missed a vsync
pulse it needed and that it should speed-up a bit in response
Change-Id: I9d6be037737e9283297898cac2e3563453e797cd
|
|
Bug: 17440886
Change-Id: I1f2d98c63ec1a2814c2258cf7e0096139263770a
|
|
Bug: 17228458
Change-Id: Id884a429a512f9cd2be0ed16dbd0f10e92b4440d
|
|
Bug: 14444180
Change-Id: I68bec3807c4d1c88d5af1aec2fe6907d60b5f2f3
|
