History log of /frameworks/base/libs/hwui/renderthread/TimeLord.h
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
501ff9acfe9dd656c1fb6d82ec0533c3244fd88b 17-Jun-2016 John Reck <jreck@google.com> Avoid re-calculating vsync mid-frame

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
/frameworks/base/libs/hwui/renderthread/TimeLord.h
ba6adf66d3c44c0aa2fd8a224862ff1901d64300 19-Feb-2015 John Reck <jreck@google.com> Initial attempt at jank-tracking stat collection

Is a bit naive, perhaps overly aggressive, but sorta works

Change-Id: I01a774e00dbe681439c02557d9728ae43c45ce50
/frameworks/base/libs/hwui/renderthread/TimeLord.h
a733f89c05567c97359169832f41389b939baaad 19-Dec-2014 John Reck <jreck@google.com> Tweak RT-animator scheduling

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
/frameworks/base/libs/hwui/renderthread/TimeLord.h
119907cd2575c56b1ebf66348b52e67aaf6a88d8 14-Aug-2014 John Reck <jreck@google.com> Animator stuff

Bug: 17228458

Change-Id: Id884a429a512f9cd2be0ed16dbd0f10e92b4440d
/frameworks/base/libs/hwui/renderthread/TimeLord.h
18f16e6fba74eda173e1e7c869e6e2e2acc073ff 03-May-2014 John Reck <jreck@google.com> TIME LORD!

Bug: 14444180

Change-Id: I68bec3807c4d1c88d5af1aec2fe6907d60b5f2f3
/frameworks/base/libs/hwui/renderthread/TimeLord.h