- Is there some details about 1.7. alpha 6 change ...
# compose
t
• Is there some details about 1.7. alpha 6 change : Improved performance of
updateTransition
API. ? The only thing I can find would be https://github.com/androidx/androidx/commit/fa28aa1ca5fd8b0d2b82802fc346a1b1ad3b8ddb @jossiwolf I now have random bugs with
Crossfade
that reach a state where it no more transition between the states despite everything looking OK.
The code:
Copy code
logError("AAAA") {"Precross: $isBuffering"}
Crossfade(targetState = isBuffering, label = "") { isBuffering ->
    logError("AAAA") {"cross: $isBuffering"}
    if (isBuffering) {
        CircularProgressIndicator(
            modifier = Modifier
                .size(48.dp)
                .padding(4.dp)
                .align(Alignment.Center),
            strokeCap = StrokeCap.Round,
            strokeWidth = 2.dp,
            color = buttonColor.copy(alpha = 0.45f),
        )
    }
}
The log :
Copy code
CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5.invoke@413: Precross: true
CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5$2$4.invoke@370: cross: false
CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5$2$4.invoke@370: cross: true
CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5.invoke@413: Precross: false
CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5$2$4.invoke@370: cross: false
CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5$2$4.invoke@370: cross: true
CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5.invoke@413: Precross: false
CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5$2$4.invoke@370: cross: false
CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5$2$4.invoke@370: cross: true
But the buffering animation is still shown despite the state being false, and the Crossfade properly being called.
Actually taking logs from the start shows a different result.
Copy code
17:22:26.267 CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5.invoke@411: Precross: false
17:22:26.269 CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5$2$4.invoke@368: cross: false
17:22:31.839 CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5.invoke@411: Precross: false
17:22:31.846 CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5$2$4.invoke@368: cross: false
17:22:35.572 CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5.invoke@411: Precross: false
17:22:35.576 CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5$2$4.invoke@368: cross: false
17:22:36.412 CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5.invoke@411: Precross: false
17:22:36.413 CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5$2$4.invoke@368: cross: false
17:22:40.044 CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5.invoke@411: Precross: false
17:22:40.045 CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5$2$4.invoke@368: cross: false
17:22:40.363 CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5.invoke@411: Precross: false
17:22:40.364 CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5$2$4.invoke@368: cross: false
17:22:40.615 CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5.invoke@411: Precross: false
17:22:40.624 CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5$2$4.invoke@368: cross: false
17:22:40.886 CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5.invoke@411: Precross: false
17:22:40.887 CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5$2$4.invoke@368: cross: false
17:22:41.381 CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5.invoke@411: Precross: true
17:22:41.383 CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5$2$4.invoke@368: cross: false
17:22:41.387 CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5$2$4.invoke@368: cross: true
17:22:41.795 CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5.invoke@411: Precross: false
17:22:41.797 CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5$2$4.invoke@368: cross: true
17:22:41.797 CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5$2$4.invoke@368: cross: false
17:22:41.987 CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5.invoke@411: Precross: false
17:22:41.989 CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5$2$4.invoke@368: cross: true
17:22:41.991 CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5$2$4.invoke@368: cross: false
17:22:46.917 CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5.invoke@411: Precross: false
17:22:46.923 CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5$2$4.invoke@368: cross: false
17:22:47.067 CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5.invoke@411: Precross: false
17:22:47.069 CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5$2$4.invoke@368: cross: false
17:22:48.584 CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5.invoke@411: Precross: false
17:22:48.585 CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5$2$4.invoke@368: cross: false
17:22:48.798 CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5.invoke@411: Precross: true
17:22:48.799 CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5$2$4.invoke@368: cross: false
17:22:48.801 CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5$2$4.invoke@368: cross: true
17:22:49.183 CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5.invoke@411: Precross: false
17:22:49.185 CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5$2$4.invoke@368: cross: false
17:22:49.187 CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5$2$4.invoke@368: cross: true
17:22:49.495 CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5.invoke@411: Precross: false
17:22:49.496 CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5$2$4.invoke@368: cross: false
17:22:49.497 CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5$2$4.invoke@368: cross: true
Seems it's not supposed to call with both states.
Note that it can also be locked in the other state and any future change have no effects.
d
Re: No transition when there's supposed to be transition I recently submitted a fix for that, as a part of the shared element transition change. Can you try and see if the issue is still reproducible with the latest snapshot? Also, to clarify, it is expected to see both the initial and target states to be composed during the transition. That's how we obtain the outgoing content in order to fade it out. Once the transition reaches target state, you can expect the initial state to stop composing.
t
Thanks I'll try tomorrow. For the both targets, yes I know but as you see, even when the state does not change and there composition for something else the content is called twice with true as the second target even if the state is always at false. And once in that state any change of the state will still always render both state in the same order.
d
even if the state is always false
I'm seeing
17:22:41.381 CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5.invoke@411: Precross: true
in the second log that lasts for one frame, twice. With that target change, I'm expecting to see both states start to be composed.
t
Yes those are the expected ones with the true as the second composition. But what I expected would be that when the state goes back to false, I see a double true then false, and that after only false right?
d
When the target is changed from
false
->
true
, the animation is already started, going to
false
in the next frame interrupts the animation with a new target value, which will take a couple of frames to reach. I'd expect this same behavior for releases prior to alpha06.
t
Kid don't want to sleep so I quickly tested last snapshot the issue seems to be resolved. Is alpha 7 already cut?
For the logs:
Copy code
19:58:29.755  CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5.invoke@393: Precross: true
19:58:29.756  CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5$1$4.invoke@356: cross: false
19:58:29.758  CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5$1$4.invoke@356: cross: true
19:58:29.767  CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5.invoke@393: Precross: true
19:58:29.783  CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5$1$4.invoke@356: cross: false
19:58:29.784  CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5$1$4.invoke@356: cross: true
19:58:30.854  CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5.invoke@393: Precross: true
19:58:30.860  CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5$1$4.invoke@356: cross: true
19:58:30.977  CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5.invoke@393: Precross: false
19:58:30.978  CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5$1$4.invoke@356: cross: true
19:58:30.996  CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5$1$4.invoke@356: cross: false
19:58:36.794  CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5.invoke@393: Precross: false
19:58:36.796  CompactPlayerKt$CompactPlayer$4$1$1$1$1$2$5$1$4.invoke@356: cross: false
The new ones looks normal to me now, change to true trigger the false / true, the second is too fast so reset the animation. then still true so only render true then switch to false I see a true then false, then the next ones are just false.
d
Ok, I'm glad the issue is resolved. alpha7 isn't out yet. It's scheduled to release in ~10 days.
t
Yes it's not out I know the schedule, but usually the target commit is chosen a long time before. I'll check the commit history.
So no it's not cut yet, perfect. Thanks for the fix, but not thanks for forcing me to have a build with sharedtransitions forcing me to play with that 😛
😂 2
d
Yea, the build is usually cut a week before release.
t
Perfect, I don't know why but currently with snapshots there's gradle cache issues, and it tries to download desktop modules for the snapshots that does not exist and so are not cached and slow down my builds a lot. (But unrelated to this)
d
Worth filing a bug.
👍 1
t
On that snapshot I got a strange issue with the new
animateItem
when going home then back to the app the items are fade out. The strange part is that the code I use is
Copy code
animateItem(
        placementSpec = spring(
            stiffness = Spring.StiffnessMediumLow,
            visibilityThreshold = IntOffset.VisibilityThreshold,
        ),
        fadeInSpec = null,
        fadeOutSpec = null,
    )
So there should not be any fade animations.
d
That's a separate issue for sure, because
animateItem
uses
Animatable
instead of
Transition
. Could you file a bug please?
t
Won't before next week at least. Seems it's race or something as it does not happen on all devices :(
Tested a new snapshot as it was expanded to lazygrid and while I still do not have a proper repro the issue spread to them too so opened https://issuetracker.google.com/issues/333608687 @Andrey Kulikov so that it can be triaged and you can tell me what more may be needed so I can try to repro next week.
👍 1
a
I will take a look, thanks
t
See my last comment there it's really strange. Can try to find 1h tomorrow CET time if you need me to test things to help pinpoint.
@Andrey Kulikov were you able to repro with the other guy sample or should I plan sometime this week to provide more details ?
a
Unfortunately I wasn’t able to reproduce it yet. Please ping me if you know how to help. Thanks
t
@Andrey Kulikov it's more the opposite 😞 As always with those strange bugs I have no idea where to start looking, so I need pointers to where / what to look to build a repro.
BTW https://issuetracker.google.com/issues/333672195 was just unassigned ... If you could triage it too as it's lazy stuff.
a
As the author of another bug already shared the code I was really hoping it will help to reproduce. But unfortunately it wasn’t enough yet. you mentioned that you were able to reproduce it on Android 14 and only with release build, right? will you be able to reproduce it on emulator?
t
I've added a comment there I have not yet tested on the emulator.
I did not plan time for that today, but will try on emulator when I can today, any particular API level wanted ?
a
I just need to reproduce it for now, so any API level where it will not work. once I repro it, I will verify what api levels are affected
t
A quick note here to not spam the tracker and not sure it's relevant but on the video I posted there's clearly a "fade" effect when coming back the items are visible and fade out unlike when we touch them and they instantly appears. But it can be an android thing that fade the last saved image and the new one during app return.
Ok so @Andrey Kulikov On pixel 6 pro emulator it does not behave the same, it's very hard to repro but I managed to get to broken state
Normal state being so only a part of the row is missing ...
As a side note, when it happens on the real phones, (so you do the go home, start another app, return to app to trigger it) then it will happen each time you go home then back to the app, no more need to start another app to trigger that. Even if I completely leave that screen and return to it it will always fade out.
Kill the app, start it again, and now you can go home and back without any issues until I start another app and then it's broken.
a
I was able to reproduce it on samsung device. will investigate
👍 1
t
@Andrey Kulikov is that new graphic layer used in more places in the last snapshots ? It now happens to the whole app with the same symptoms.
a
yes, it is used by default there. we will try to find a solution before cutting next alpha
t
Ok thanks again, reverting and won't open a duplicate issue then.
Seems A8 was just cut 😞 Sounds risky for next alpha.
a
we cut on wednesdays (week before release)
t
Usually yes but from my understanding it happens when the version is committed and it was https://github.com/androidx/androidx/commit/65604b92777345051d6d5e437a9a068ef4cdc299 hence the remark.
a
no, such cls shouldn’t affect the schedule as I know
t
Ok thanks. BTW I'm trying to repro https://issuetracker.google.com/issues/333672195 as it's my main prod crash and can't figure out anything. Do you have any clue at what I should be looking for ?
@Andrey Kulikov sorry to bother you again, I wanted to test the fix, but snapshots are now force linked to core 1.13.1 that is not yet released. And
Copy code
configurations.all {
    resolutionStrategy {
        force("androidx.core:core:1.13.0")
    }
}
Does not seem to work. Is there something I'm missing for the forced resolution?
a
Sorry, I don’t know how this part works
t
Thanks, forcing the version in each module that had a transitive dep did work. I'm still puzzled by how gradle works sometimes.
Seems the global app bug is fixed, unfortunately M3 bottomsheets are again not usable 😞 https://issuetracker.google.com/issues/336962418 if you know who to ping 😞
@Andrey Kulikov sorry but a new one probably for you 😞 https://issuetracker.google.com/issues/340582183
@Andrey Kulikov actually seems like a major one I've added more details.
It does not occur with 1.7 B1.
a
we will take a look, thanks
t
Seems there's https://android-review.googlesource.com/c/platform/frameworks/support/+/3086717, sorry on my phone did not update the issue
a
yes, I just merged this revert
t
Thanks.
For the record the layer issue is back with last snapshots. I commented on https://issuetracker.google.com/issues/333584635
@Andrey Kulikov Is there still some known issue with the layer stuff? Got an user on Android 14 OnePlus - CPH2451 reporting that some icons disappear after going home screen off, screen on return to app. If not I can try to open an issue, but no repro and for the moment no other reports 😞
a
if you test it with a build containing https://android-review.googlesource.com/c/platform/frameworks/support/+/3094566 then no, it is not a known issue
t
Arf thanks, seems I missed that one, wanted to quickly have a build without the ANRs from font loading 😞 Will it be in beta 2?
a
yes, it should be
❤️ 1
t
@Andrey Kulikov So sorry to bother you again but now with beta 2 there's noticeable lag on release builds with screen with many lazy layouts. Are your very last CLs related to a know perf regression or should I open an issue ? (I went from snapshot 11845184 to Beta 2)
And there's a crash with beta 2 https://issuetracker.google.com/issues/343750859 reported by another user, not triaged yet as in root of Compose.
a
hey! re: triaging. we have internal triage rotation and you can be assured that every bug filed in compose should be triaged within a week. if it didn’t happen in this timeframe, feel free to ping someone from our team
for noticeable lag, I did merge a few optimazations, but it doesn’t necessary mean it was for the same issue. it will be safer to file a bug so we can investigate, if it is possible. thanks
t
In all sections ? Usually those without auto assignment to someone are ignored, maybe it have changed. No more at computer but added a comment about another crash with begin record. Beta 2 is very unstable. Will report more tomorrow and roll back again, the missing images touched a lot less users. Will see next week to report the lag, but it does not happen on all phone will be again a fun one :( That 1.7 release is complicated.
a
there should be some triage process in every compose related subcomponent. if you notice that your compose related bug is not triaged within a week please contact someone from google to investigate why we missed that
t
Checking quickly it seems yes they are somehow assigned but then forgotten like https://issuetracker.google.com/issues/317561689 that still requires a sneaky try catch via a restricted API to workaround. Anyway I now know Googlers for quite a few sections to ping but not yet in all. But I now the tracker is spammed too so unless it's critical without workaround I usually let it go. It's just that for Compose 1.7 I do not remember not having a single build snapshot included without issues, making every release quite stressful.
BTW too busy with too many things to try to repro the lag issue but just found https://issuetracker.google.com/issues/343938070 that is one week old, related to perf and I have the exact same logs that I did not notice. Looks imagereader and new layers related so for you or nader ? I still have those logs with 11936670 that have all your last stuff too.
a
assigned on Nader, thanks
t
And may I ask that you reopen https://issuetracker.google.com/issues/343750859 ? Would help a little my nerves for the week end.
Do you have some insight about the opened revert and decision for the crash?
a
Hey. Nader is away this week, I will try to work on fixing this crash while he is away
reverts are related to an issue we are investigating internally. seems like it is related to robolectric only, so the main logic will not be reverted, don’t worry
t
Thanks, this is really a pain as blocked in prod with users missing layers and unable to update without crash or lags. One user fully debug the issue to modifying the scattermap inside the foreach, so at least the cause is well known now.
a
yes, thank you both for this investigation
t
Well I've ordered a new ssd to dual boot linux to be able to compile androidx and be less blocked by Windows, so will probably be better in the future.
Thanks a lot for the fix.
And there's still something odd 😞 With 11999773 very very rarely I have some part of the app full black. Like all the content from a bottomsheet (not modal so inside of the app, the compact and expanded stay black) rotation restore it. Since I'm animate a lot of stuff in the sheet during opening / closing, this sounds like a layer issue. As with all those, no repro.
a
does it happen on top of content which is SurfaceView inside AndroidView composable? like maps/video player/etc?
t
No normal single compose view, so far only happened inside a bottom sheet scaffold. I'm waiting for GPlay to validate the release in beta to get more user feedback and details. Only happened once for me and the other user who had that version. Once I know more I'll try to open another issue, just wanted to let you know as 1.7 final is approaching fast.
@Andrey Kulikov So it's in beta and also got users showing some blinking on a simple Canvas drawing with paths. I guess this creates graphics layers too? But this is again in the same app with a single Compose activity and one setContent So it does not seems to be the same blinking issue you are working on. (See between 0:23 and 0:24) in attached video. Should I report that without a repro?
a
yes, please report
t
Opened https://issuetracker.google.com/issues/349054828 will add more details if I can gather more.
@Andrey Kulikov And me again 😞 https://issuetracker.google.com/issues/350350576 Major performance regression in today's snapshots versus a couple of days ago, and a Nader patch was merged between. Since he does not really communicate with us, I'm informing you for triage.