Status Update
Comments
en...@google.com <en...@google.com>
an...@gmail.com <an...@gmail.com> #2
This also brings back dialog content size animations issues :( But on all devices this time.
See attached video
Repro:
Dialog(
onDismissRequest = {
if (dialogState.canDismiss.value) {
dialogNavigator.hide()
}
},
properties = properties,
content = {
Surface(
modifier = modifier
.safeContentPadding()
.fillMaxWidth(0.8f)
.animateContentSize(),
shape = shape,
color = backgroundColor,
contentColor = contentColor,
) {
.....A composable that change it's size
}
},
)
en...@google.com <en...@google.com> #3
Can you give a fuller example for the animateContentSize()
problem?
cc...@google.com <cc...@google.com> #4
It does that for all the cases where the content change.
properties = DialogProperties(usePlatformDefaultWidth = false)
var show by remember { mutableStateOf(false) }
LaunchedEffect(Unit) {
delay(1000)
show = true
}
Column {
Text("X")
if (show) {
Text"Y)
}
}
Edit: This was a well known long time issue when not using usePlatformDefaultWidth = false
so we were forced to workaround with that.
Now even with it it trigger that. (Depending on the phone, it's either super slow, or laggy and jumping).
en...@google.com <en...@google.com> #5
I am seeing a problem with decorFitsSystemWindows = false
where it continues to invalidate the layout even after the animation completes. I don't think that's the problem you're worried about, though.
If I understand correctly, the problem you're seeing is something about it being laggy? And it didn't happen in the previous version, right?
That problem is likely due to the Window resizing on every frame, which is more expensive than the window content resizing on every frame. In a previous iteration, the window size was full screen and the content resized itself. You can resolve this yourself by doing this:
Surface(
modifier = Modifier.safeContentPadding()
.fillMaxSize()
.wrapContentHeight()
.fillMaxWidth(0.8f)
.animateContentSize(),
...
I'll see if I can fix the problem with decorFitsSystemWindows = false
invalidating layout continuously.
en...@google.com <en...@google.com> #6
There's 2 very different issue here. The main very blocking is the Samsung dialogs from a bottomsheet/popup being at the bottom and under the navigation bar. Samsung is a very large percent of users. And a full rewrite of all M3 AlerDialog to something else to workaround is a pain as most M3 things are private / internal.
The second issue is about the huge lag.
It was present since a very long time with usePlatformDefaultWidth = true
but not with usePlatformDefaultWidth = false
now it's always present.
AFAIR previously all the workaround based on .fillMaxSize()
had issues with the dialog scrim, but I'll try again if there's a fix for the Samsung devices.
en...@google.com <en...@google.com> #7
I just verified that an AlertDialog
called from a ModalBottomSheet
from a Pixel 9XL works fine. I'll see if I can find a Samsung device to test.
en...@google.com <en...@google.com> #8
Yes this is specific to Samsung as stated in first message.
I repro via Samsung testlab as I do not have a device myself, but A54 A55 with Android 14 there does reproduce the issue. (And a few different other Android 14 samsung devices from my beta users)
Description
the relevant part of my code is:
struct ip_mreq_source mreq;
/* Set up the connection to the group */
mreq.imr_interface.s_addr = htonl(INADDR_ANY);
mreq.imr_multiaddr.s_addr = inet_addr(mcast_group);
mreq.imr_sourceaddr.s_addr = inet_addr(ssm_source);
After digging in the issue, i noted a big difference between the way the struct ip_mreq_source is declared in windows/linux and android.
on windows (winsock) and linux (netinit/in.h) the structs for setting up multicast requests and source specific multicasts requests are defined as follow:
struct ip_mreq {
struct in_addr imr_multiaddr;
struct in_addr imr_interface;
};
struct ip_mreq_source {
struct in_addr imr_multiaddr;
struct in_addr imr_sourceaddr;
struct in_addr imr_interface;
};
on bionic instead, inside of linux/in.h we have the following:
struct ip_mreq {
/* WARNING: DO NOT EDIT, AUTO-GENERATED CODE - SEE TOP FOR INSTRUCTIONS */
struct in_addr imr_multiaddr;
struct in_addr imr_interface;
};
struct ip_mreq_source {
/* WARNING: DO NOT EDIT, AUTO-GENERATED CODE - SEE TOP FOR INSTRUCTIONS */
__be32 imr_multiaddr;
__be32 imr_interface;
__be32 imr_sourceaddr;
};
as you can see ip_mreq is perfectly the same (and compatible) while for some reasons, ip_mreq_source is not.
ip_mreq_source should be re-defined as:
struct ip_mreq_source {
struct in_addr imr_multiaddr;
struct in_addr imr_sourceaddr;
struct in_addr imr_interface;
};