Status Update
No update yet.
Comments
lp...@google.com
Just noting that similar expensive inset logic is present for the framework API on new API levels, WindowManager#currentWindowMetrics seems to be unfortunately expensive too, for the case where we are only interested in window size.
Attached an example trace from a microbenchmark - calculating window metrics in this way is causing a ~10% regression to the cost of composing some compose content in this case
However note this is still cheaper than WindowMetricsCalculator's impl, since that does some extra work on top
Full numbers on API 34 for SlotTableIntegrationBenchmark.create:
- No window size calculation
timeNs min 1,452,514.7, median 1,544,064.2, max 1,667,164.9
- WindowManager#currentWindowMetrics inside onAttachedToWindow
timeNs min 1,615,371.8, median 1,691,400.3, max 1,917,655.9
- WindowMetricsCalculator#computeCurrentWindowMetrics inside onAttachedToWindow
timeNs min 1,804,849.3, median 1,973,239.9, max 2,093,855.9
So roughly 10% and 25% regressions over baseline perf
lp...@google.com
Discussed offline, the framework performance issue with WindowManager#currentWindowMetrics was fixed in API 34+, as insets are lazily calculated on newer versions
di...@google.com
This will be fixed in the next WM Jetpack release.
Description
In our case we don't even need to know about insets, so maybe this could be made optional / lazily calculated, or provide an alternate API that only calculates bounds.
Alternatively, is there a faster path that could be used to calculate insets here? Some other APIs (I'm not clear on the differences) such as `View#onApplyWindowInsets`, `View#getRootWindowInsets` / `getWindowVisibleDisplayFrame` don't seem to go through this binder call, so not sure what is causing this in this case.