Hey, how can I change the color of shadow produced...

# compose

[Ankur Gupta]

Hey, how can I change the color of shadow produced by drawShadow() modifier? I’m trying to make neumorphism design components. It would be great to have more control on shadows similar to the box-shadow property in CSS.

[Leland Richardson [G]]

Someone with more direct knowledge can probably say more here, but I think the short answer is “you can’t right now” but I’d like that to not be the case. IIUC, we are hashing out some details about how/if we could support this on earlier API levels where the graphics layer didn’t support it natively

[Leland Richardson [G]]

i think for API 28+ (or something like that) you can probably copy the drawShadow modifier and add the parameter if you want to get something working in the near term

[Leland Richardson [G]]

also feel free to file a bug on this, it might help send signal on its importance, especially i we can understand your use case more

[Sergey Y.]

hm, I thought Compose draw shadows on its own 🤔

[Leland Richardson [G]]

right now we try to use the platform’s canvas, which can draw shadows more efficiently than we can at the compose layer

[Leland Richardson [G]]

we might do it ourselves to provide the fallback behavior though

[Leland Richardson [G]]

or alternatively, bundle a newer version of skia on older APIs… but that comes with its own bag of trouble

[Sergey Y.]

Enlarged apk size due to Skia libs bundling can be reduced by using the AppBundle. Flutter is bundling with everything required and the release apk size around 4mb, which in my opinion is pretty small.
Or what else problems are you talking about?

[Leland Richardson [G]]

unlike flutter, we built compose to be embedded in a View hierarchy pretty seamlessly

[Leland Richardson [G]]

so switching canvas implementations in the middle of that is not… easy/cheap/fun

[Leland Richardson [G]]

its not just about bundle size

[Sergey Y.]

I was about to suggest if a developer needs more advanced graphics capabilities lets give him an extra compose-skia module or something like that. Which will not be a part of the Core but can be imported as a library like any other Jetpack library. ☹️

[Leland Richardson [G]]

it might be possible. like i said earlier, i’m not directly involved w/ this and i’m not a graphics programmer so i’m not the best person to comment on the tradeoffs

[Sergey Y.]

Probably @romainguy could suggest something.
Anyway thanks for the discussion.

[Leland Richardson [G]]

👍

[romainguy]

This would make interoperability with views a lot less seamless

[romainguy]

And potentially not possible with the way we do it now

[romainguy]

4 MiB is also a lot for many apps

[Leland Richardson [G]]

yeah, we already have to fight to justify kotlin stdlib

[Sergey Y.]

I forgot when last time seen a production app smaller than 4Mib.

[romainguy]

Here’s a simple example, the Square Cash app is ~14 MiB

[romainguy]

Adding 4 MiB is a large % of their existing size

[romainguy]

We know a lot of developers do care about deployment size

[romainguy]

I wish it wasn’t the case, it would make our life easier

[Sergey Y.]

Sad... Designers like to draw colorful and animated shadows.

[romainguy]

Note that you can color shadows as of API 28 (if I recall properly)

[Sergey Y.]

You are correct in API 28 we can adjust elevation color. But API 28 still far from regular development

[Sergey Y.]

@romainguy, @Leland Richardson [G] thanks for the discussion.

It inspired me to try to implement some sort of asynchronous software shadows rendering. I did something similar with a regular android view. I had to create a dynamic ambient light behind ImageView with a random picture. The "shadow" was baked on background thread by downscaling and blurring the picture.
Probably I could "pre-render" several frames to be able to simulate a shadow animation.
But the thing is I need to figure out what is the best way to integrate this with Compose. In terms of recomposition, shadow computation, and seamless integration. ✌️

[gildor]

right now we try to use the platform’s canvas, which can draw shadows more efficiently than we can at the compose layer

It may sounds reasonable if you expect that standard shadows are more common, but on practice we just replace native shadow with 9-patch or include a couple nested layouts with shadow background just to emulate shadow which designers want

I think compose definitely need custom shadow drawing modifier, even if it wouldn’t be perfectly efficient, because all ad-hoc solutions which we use probably even less efficient and often looks not so good

Now we are on position when we struggle with every custom shadow (and we have a lot of them, design team is not happy with standard material ones) and it makes developer sad when we implement it properly for every case and it makes designers sad if it was not implemented as they expected (when we cheat and use cardview or elevation for elements to avoid custom shadows)

[gildor]

and it’s not only about shadow color, but also intensity of shadow, low elevation material shadows looks as borders, so you cannot change it to make less intensive to make looks the same

[Leland Richardson [G]]

@gildor i agree with you. I want to have a fully featured shadow, where it makes the efficient choices when possible as an implementation detail. It is a bit concerning though if there is a huge performance cliff when you tweak one parameter innocently. We would have to figure out the right way to message this or lint or something if it became a problem

[gildor]

Maybe having 2 shadow modifiers would be more explicit:
drawShadow - for platfrom native shadows
drawCustomShadow - for own implementation which supports color, position etc

[Leland Richardson [G]]

yeah that’s not a bad idea. will make sure we consider that

[Leland Richardson [G]]

it gets tricky though if some of it depends on which platform you’re on

[Leland Richardson [G]]

because then its not which api you decide to use, its which platform is the code running on

[gildor]

drawCustomShadow also may use optimal platforrm implementation if API level is high enough and fallback to custom drawing otherwise

[Adrian Blanco]

I just remember from RenderScript that is was incredibly frustrating that your code would sometimes just suddenly decide to run on the slow path, and there wasn't any obvious reason why

[Leland Richardson [G]]

yeah. it’s not frustrating until it is. and then it really is.

[romainguy]

It’s unfortunately common to any solution that relies on hardware acceleration

[romainguy]

Anyway, for many cases we could generate 9patches or emulate shadows on the fly with gradients/vertex fields, based on which parameters are set

[romainguy]

But that would still mean either performance cliffs or correctness exceptions (good old convex shapes for instance)

[Ankur Gupta]

Sure Leland, I’m opening a bug on this. What I as a user see is the current implementation is oriented towards material specs, shadow is dependent on elevation of view. But a UI toolkit should be able to cater other design languages as well. Just like TextField is raw and bare bones but its implementation is provided in Material Design module. Shadow should also be customisable, eg. its opacity, radius, the sides, color etc

[Ankur Gupta]

One more reason I could give is, even in physical world all shadows are not grey/black. A opaque object cast the shadow of its own color.

[Leland Richardson [G]]

Thank you for filling! I completely agree

[romainguy]

The 3d rendering engineer in me has to be pendantic here: an opaque object certainly does not cast a colored shadow no. A transparent object would, but that's a wrong way to think about it. Shadows are the absence of light, not the presence of something. Any coloration you may see is either transmitted (transparent objects) or received from other light sources (including light bounces). And if you want to go by the physical world analogy then material shadows are the right shadows (since they are properly computed by projecting a light area through an object). What you are asking for is non physically based shadows. End of the pendantic sidebar :))

[Ankur Gupta]

Oops I meant to say Translucent. So I stand corrected. But please also understand that material design just assumes the light source is at the above the surface/top. This assumption alone limits many design implementation which I'm talking about. Allowing to change color can give us ability to change the light source and possibly glow effect.
Here are the example designs-

[Ankur Gupta]

[romainguy]

I'm aware of such designs yes. That's why recent versions of Android let you move the light source and change colors btw. Anyway I'm not disputing the need for more customization.

[Colton Idle]

@Ankur Gupta my designer asked me to implement something like this today. Do you have a link to the bug so I can star it?

[Ankur Gupta]

@Colton Idle Sure. Here it is https://issuetracker.google.com/issues/160665122