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.

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

hm, I thought Compose draw shadows on its own 🤔

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

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?

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

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. ☹️

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

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

👍

This would make interoperability with views a lot less seamless

yeah, we already have to fight to justify kotlin stdlib

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

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

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

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

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

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 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

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

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

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

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

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

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

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

Thank you for filling! I completely agree

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 :))

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-

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.

@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?

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