IssueTracker

Looking at the CL, I'm not sure how it could cause a regression. It looks like a change in the linter. Is it possible that we had a device change during that time?

When the dashboard files a bug it unfortunately puts a wrong CL range. It is this one: aosp/1362976

As far as the benchmark regressions are concerned, I believe this particular benchmark incurs more overhead in the worse case scenario that might not map directly to re-world performance. Because we are drawing text into a separate layer first, we are paying an additional (usually one time cost) of this caching work. However, we would see a benefit of subsequent draws of text being much faster as long as the text content doesn't change.

In androidx.ui.benchmark.test.TextInColumnBenchmark_first_draw_100_ we see a regression because this test repeatedly tears down and rebuilds the compose UI. This requires fully reconstructing the entire text composable as well as the overhead associated with creating the layer which we did not have before.

Similarly in androidx.ui.benchmark.test.TextInColumnBenchmark_toggleRectangleColor_draw_100_ it looks like each time the toggle is changed, we are modifying the font size which again would require recreating the layer before drawing again negatively impacting this particular benchmark's performance.

Alternatively, this would explain the performance improvements that we are seeing in the Checkbox/RadioGroup test cases. In these cases we are toggling state that ends up modifying the Checkbox or RadioGroup but not the Text composable across recompositions. We are seeing the performance gain of drawing the content from the separate layer rather than having to draw the text directly to the screen.

Generally, this seems like a tradeoff between startup benchmarks and iterative ones. If we invest in solutions to cache and re-use results across invocations, we will see benchmark improvements across subsequent draw calls, however, we will see performance regressions in startup performance. I think it is great we are tracking the differences across all benchmarks but in this particular scenario it might be more appropriate to see how this particular change behaves in more real world scenarios. From a personal perspective, I think this change is an overall benefit as we would see better performance in animation like scenarios especially when UI elements around the Text are changing which would cause re-draws for the AndroidComposeView or other layer the composables might be animating within.

We might be able to improve the performance of this by reusing layers.

I agree with you Nader that we definitely care more about "frequent" updates rather than one time cases (unless we start considering cases like recycler view). But I just file a bug for any performance change and let the owners to decide on the strategy as I don't have enough context to make the call.

I tried caching layers (per AndroidComposeView) and am not able to significantly affect the performance. I think the performance problems may be due to reflection calls in the View implementation. I will experiment with this.

I've confirmed on Pixel 6 that "google-sans-text-medium" loads a GS text font - see attached.

Can you get a minimal repro for this one? It looks likely that it could just be using the wrong font at that application.

Reproduced by loading in background. Appears related to DeviceFontFamilyName variation setting from a background thread leaking somehow.

For Google Sans Text please specialize the opsz when loading it.

You can either

1. Disable load-time font variation settings

@OptIn(ExperimentalTextApi::class)
val GoogleSansText500Medium = Font(
    DeviceFontFamilyName("google-sans-text-medium"),
    weight = FontWeight.W500,
    variationSettings = FontVariation.Settings() /* don't specialize font variation, leaving opsz alone */
)

2. Intentionally specialize the font variation settings, including explicit opsz

@OptIn(ExperimentalTextApi::class)
val GoogleSansText500Medium = Font(
    DeviceFontFamilyName("google-sans-text-medium"),
    weight = FontWeight.W500,
    variationSettings = FontVariation.Settings(
        FontWeight.W500,
        FontStyle.Companion.Normal,
        // opsz <=17f for Google Sans Text
        // opsz >=18f for Google Sans
        FontVariation.Setting("opsz", 17f)  
    )
)

What's going on

When opsz is not provided, the default behavior of specializing variation settings to (Weight Style) causes opsz to be reset to the default value, which is "Google Sans"

By explicitly skipping variation settings, or setting opsz you're ensuring that either (1) the system loaded typeface or (2) the desired specialization is used exactly.

This bug was linked in a change in the following release(s):

• androidx.compose.ui:ui-text:1.3.0-rc01