| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
InputEventAssigner does not currently get notified about all frames. In
the existing logic, only the cases for batched consumption would be
counted as 'choreographer callback'. This misses several cases, such as:
1) CALLBACK_INPUT was never scheduled, but a frame is produced
2) CALLBACK_INPUT was scheduled, but no events were consumed
However, it is critical that InputEventAssigner knows about all frames,
because it needs to reset the 'down' state for proper frame attribution.
At the same time, we refactor the logic in InputEventAssigner. In the
updated logic, we will specifically store the event id with ACTION_DOWN
only. In all other cases, we will use the current / latest input event.
In this CL, we reset the 'down' state after the input event id is
used for the current frame. A good proxy for that is the
ThreadedRenderer::draw call, which in turns
calls attachInfo.mViewRootImpl.getUpdatedFrameInfo().
Also, rename "onChoreographerCallback" since it's not exactly clear
which callback this is referring to. In the new logic, this callback
will happen from 'draw'/'onDraw' functions.
Bug: 167947340
Test: add LOG_ALWAYS_FATAL crashes in LatencyTracker for duplicate
'reportTimeline' calls. The crashes are gone after this CL.
Change-Id: I5fad6665d10e0594963209b138e9bd2bdf00ca38
|
|
|
When a frame is determined to be caused by an input event, it will be
labeled with a specific input event id. The newly added entity,
InputEventAssigner, is responsible for determining which input
event we should use.
For regular ACTION_MOVE events, we will take the latest input event as
the event that has caused the frame. For the initial gesture
(ACTION_DOWN), we will use the first event (the ACTION_DOWN itself) to
figure out the down latency. This will allow us to split up 'down' and
'scroll' latencies.
Bug: 169866723
Test: looked at the data printed locally to logcat
Test: atest InputTests
Change-Id: I8513a36960e5d652d07655d1267e758d0c59ced7
|
