Status Update
No update yet.
Comments
cc...@google.com
ap...@google.com
ap...@google.com
Branch: androidx-master-dev
commit 3ed3fb003fa6c1244f923202859a616225b5b2fa
Author: Ian Lake <ilake@google.com>
Date: Fri Feb 14 11:17:46 2020
Create an interface for layouts that can be opened
Create a common interface that represents layouts
that have two states: open and closed. This allows
higher level libraries to rely on the interface,
rather than concrete implementations such as
DrawerLayout, making them more resilient to
changes in the current recommended implementation.
Fixes: 129979320
Test: ./gradlew checkApi
Change-Id: I0f2a1414977825aa053c6555261f2b7d4417bd19
M customview/customview/api/1.1.0-alpha02.txt
M customview/customview/api/current.txt
M customview/customview/api/public_plus_experimental_1.1.0-alpha02.txt
M customview/customview/api/public_plus_experimental_current.txt
M customview/customview/api/restricted_1.1.0-alpha02.txt
M customview/customview/api/restricted_current.txt
A customview/customview/src/main/java/androidx/customview/widget/Openable.java
M drawerlayout/drawerlayout/api/1.1.0-alpha03.txt
M drawerlayout/drawerlayout/api/current.txt
M drawerlayout/drawerlayout/api/public_plus_experimental_1.1.0-alpha03.txt
M drawerlayout/drawerlayout/api/public_plus_experimental_current.txt
M drawerlayout/drawerlayout/api/restricted_1.1.0-alpha03.txt
M drawerlayout/drawerlayout/api/restricted_current.txt
M drawerlayout/drawerlayout/build.gradle
M drawerlayout/drawerlayout/src/main/java/androidx/drawerlayout/widget/DrawerLayout.java
M jetifier/jetifier/migration.config
M slidingpanelayout/slidingpanelayout/api/1.1.0-alpha01.txt
M slidingpanelayout/slidingpanelayout/api/current.txt
M slidingpanelayout/slidingpanelayout/api/public_plus_experimental_1.1.0-alpha01.txt
M slidingpanelayout/slidingpanelayout/api/public_plus_experimental_current.txt
M slidingpanelayout/slidingpanelayout/api/restricted_1.1.0-alpha01.txt
M slidingpanelayout/slidingpanelayout/api/restricted_current.txt
M slidingpanelayout/slidingpanelayout/src/main/java/androidx/slidingpanelayout/widget/SlidingPaneLayout.java
ap...@google.com
Branch: androidx-main
commit 74638b3f1fd47614a3655a7a911914c0d33d7ea7
Author: Chris Craik <ccraik@google.com>
Date: Mon Jan 29 15:26:05 2024
Create alternate frame timing metric, and fix unterminated frames
Bug: 322232828
Test: FrameTimingQueryTest
Relnote: "Fixes issue where unterminated frames at the beginning and
end of the trace could be paired together, which would incorrectly
report as a single extremely long frame."
Creates alternative frameDurationFullMs metric implementation, which
isn't yet used in FrameTimingMetric but can be used to account for
vsync intended delays on UI thread.
Also fixes an issue that became more visible when validating its
measurements in traces.
Change-Id: I393531f8cf983b2700c419c00a9c7c47ec382e67
M benchmark/benchmark-macro/src/androidTest/java/androidx/benchmark/macro/perfetto/FrameTimingQueryTest.kt
M benchmark/benchmark-macro/src/main/java/androidx/benchmark/macro/perfetto/FrameTimingQuery.kt
cc...@google.com
Bumping in priority after some discussions with +Andrew and +Leland.
We found that in CI, we saw fluctuations in both frame timing and frame overrun due to buffer stuffing periodically hitting Sargo API 31.
Periodically we'd see very large spikes in P90 frame timing because randomly more than 10% of interactions would hit triple buffering, and thus have an additional 16+ms of latency. I expect gfxinfo is less significantly affected since that's median of 90th percentile frame time across each iteration.
There's more to investigate though in instability in the other scenarios, however, and this noise from buffer stuffing is likely not the only issue.
I'd like to move us to something that accounts for buffer stuffing more generally, will file blocker bugs for improvements to perfetto frame timing metrics.
jj...@google.com
Would disabling triple buffering be an option here?
cc...@google.com
For app developer macrobenchmarks, that would be great. How do we do that? (ideally on user builds too)
Description
FrameTimingMetrichas a few issues that make it hard to align with user impact, from internal feedback/discussions:frameDurationCpuMsaccounts for the UI slice, but surprisingly doesn't account for any main thread delays from runnables that delay Choreographer#doFrame from starting. (This was an old decision to keep behavior consistent both pre 31 and post 31, when expected/actual frames were available, should consider revisiting.)frameOverrunMsdoes account for delays, but still treats runnables different from in-frame work, due to how out-of-frame runnable main thread delays will delay the expected frame in the frame timeline.