Present time is available to apps, but is not currently stored inside
FrameInfo. In this CL, we add a location for storing the present time inside
FrameInfo.
Currently, the metrics reporter is triggered after the buffer is sent to
SurfaceFlinger. That means, metrics for anything that happens after gpu
draw completes are currently not available.
In a future CL, we will populate the 'presentTime' field.
In a future CL, we will register a metrics observer inside ViewRootImpl
in order to send this data to InputDispatcher. This will enable
end-to-end touch latency metrics collection.
Bug: 169866723
Test: printed present time inside FrameTimeline.cpp (surfaceflinger
side) and compared to the values printed inside a metrics observer
registered in ViewRootImpl (not done in this CL)
Test: atest ViewFrameInfoTest
Change-Id: I7d0f8c5d7b5a2572abdc4e107123e8938a36f582
- Add SurfaceStatsCallback to TransactionCompletedListener
- Register a callback in RenderProxy to be called when we have
surface stats from SF via the BLAST callback.
- Instead of finishing a frame for frame metrics reporting
immediately, wait until BLAST callback fires, note GPU completion
time and finish frame.
- Expose GPU_COMPLETION in FrameMetrics
- Modify TOTAL_DURATION to also include GPU_COMPLETION
Test: FrameMetricsListenerTest
Fixes: 171046219
Change-Id: I16fa1d80cfc4e7a5527c18fec7e885409f17ee4d
FrameInfo will now be per-window; that is, per-ViewRootImpl.
Some of the information should remain “global” (it remain in Choreographer),
while some information is going to become ViewRootImpl-specific.
Before the information gets passed to the native layer,
the ViewRootImpl-specific info will be stitched together
with the general Choreographer info.
This change is useful in order to correctly correlate frames with a specific
input event. In the unlikely scenario of a user touching two windows of the
same app simultaneously, this change will allow us to correctly measure the
latency of both frames produced by the windows.
Design doc: https://docs.google.com/document/d/1KMpMBlOxnl7zkWBCbXZZE6ZlaHEA4efYnN6WYK8n3FE/edit?resourcekey=0-eqooVNP0SskupljlTFvtOQ
Test: atest ViewFrameInfoTest
Bug: 169866723
Change-Id: Ib0bf9cd51cbcc0b9b70460c929c480eb490ec322
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
Bug: 30587465
Someday maybe the technology will exist to
allow sharing a simple constant between
Java and C++, but today is not that day.
Change-Id: I17694746cb8712058133cd5ea10c47b9909f740b
Bug: 30440166
If we are using HWC2, there's a change in timing
when in triple buffering with the pipelined offsets.
This changes JankTracker to recognize that and silently
erase that from the total duration
Change-Id: Ib1fd4209070f17dbd2baed707c8cf73fb11c3cf2
Bug: 20853441
Calculating duration that crosses the UI-RT
sync point will now subtract out the time spent waiting
in queue under the assumption that this time will be
accounted for in the previous frame's metrics
Change-Id: Ia8213f4410638840613f5ae439e98dfb77532a6a