Is there a way to fix Material3 surface ShadowElev...

# compose

[Tolriq]

Is there a way to fix Material3 surface ShadowElevation direction ? Depending on the orientation of the phone the shadow is either casted <- or ->. This does not really feels right.

[Adam Powell]

Got a screenshot? Shadows on Android use a more global illumination model that comes from the platform itself, so depending on where on screen the element is, the shadows will be shifted accordingly. If you have a screenshot we could take a look in case something is going off though

[Tolriq]

Landscape 1

[Tolriq]

Rotate the phone 180

[Tolriq]

Shadow is cast in the opposite direction

[Tolriq]

Android 12 P6 pro

[Adam Powell]

hmm, the left/right shift isn't entirely surprising since the screen is offset left or right similarly with the pillarboxing, but the difference on the top stands out. @Nader Jawad does that look right to you?

[Tolriq]

So on a phone without a cutout the shadow would be stable ?

[Tolriq]

Ok so tested on emulator and yes it's stable and looks better 😞

[Tolriq]

Is there any hack I could use to simulate that with some window attributes ?

[Adam Powell]

Nader might know some associated parameter APIs for shadows here

[Tolriq]

Ok thanks will wait for his advice then. It's not a very big deal, but since I've seen it I can't unsee, specially after seeing the way better one on no cutout devices.

[Tolriq]

For reference

[Colton Idle]

this design looks cool tolriq 😄

[Tolriq]

https://play.google.com/store/apps/details?id=app.symfonik.music.player in prod now :) I hate this shadow issue. But since it does the same with normal views I doubt anything will be possible :(

[Nader Jawad]

I do recall seeing a related issue but please file a bug and include screenshots/ sample code.

[Nader Jawad]

Off the top of my head I can only imagine that some of the graphicsLayers maybe cached a little bit too aggressively but I'm not entirely certain of that. One thing you could try is to use the Modifier.graphicsLayer overload that takes in a lamba to configure the shadow properties and use do a state read within that lambda/update state to see if it fixes it?

Also looking at the screenshot I am assuming this is being rendered within a window/dialog as well? I think that might be related. I would assume if the shadow was configured locally we it might not reproduce?

[Tolriq]

@Nader Jawad This is happening with a shadowElevation on a M3 surface so in this case no window/dialog. But after more tests this happens also on the view side of things with a normal bottomsheet. The cutoutinset does impact the shadow in all cases. So not sure where I should open the issue since it does not seems to be compose specific after all.