3 ms·

Another really annoying fact about drop shadows, is that Android choose to implement the light source pretty much where your nose is. So when a view with drop s

Another really annoying fact about drop shadows, is that Android choose to implement the light source pretty much where your nose is. So when a view with drop shadow moves closer to the bottom of the screen, its drop shadow increase visibility at the bottom of the view and decrease visibility at the top. This makes it's impossible to match specs given by designers on Android.

chrismorgan 3y ago
Can you show pictures or something of what you mean? I can’t find any mention of what you describe, and it would surprise me greatly to encounter a point light source rather than a distant light source, partly because of how fiendishly complicated it makes implementation (including just being impossible on the web), and partly just because we’re mostly used to distant light sources for illumination.
- vesinisa 3y ago
  I think they're referring to this: https://m2.material.io/design/environment/light-shadows.html https://m2.material.io/design/environment/light-shadows.html Notice how there are actually two shadows that must be combined. The point light source shadow rendering depends on the object position on screen.
  - ghusbands 3y ago
    A point light source can be at infinity. I don't think that design document implies that shadows need to change based on screen position. Note that "elevation" is about how far 'off' the background the element is pretending to be.
  - chrismorgan 3y ago
    They’re two shadows, but nothing calls them point sources; I claim that any reasonable implementer would from such descriptions absolutely presume them to be distant (as in, never have it even occur to them it might be otherwise). The only detail that seems confusing and could support otherwise is the sentence “On the web, shadows are depicted by manipulating the y-axis only.” (I’m using roughly SVG’s terminology: fePointLight has x, y and z, which can be approximately infinitely far away but it’ll only be approximately so, and feDistantLight, which has azimuth and elevation, and projects from infinity.)
- burnedtoast 3y ago
  https://pasteboard.co/AUrdZZe5KxoO.png https://pasteboard.co/AUrdZZe5KxoO.png In this screenshot all the views have the exact same spec: 8dp elevation.
  - ghusbands 3y ago
    Do you see this in all apps or just custom/particular ones? Can you control where the key light is at all? It would be surprising for the key light to be so close to the screen (rather than nearer infinity), given that the design document linked elsewhere seems to expect consistency at particular elevations.
    - burnedtoast 3y ago
      It's the behavior for all apps and I don't think it can be customized. There are some APIs to affect the spot shadow color and ambient shadow color (from API 28), but no way to affect this offset / light source position AFAIK.
  - chrismorgan 3y ago
    OK, now I’m interested in whether there’s any x-axis cast (which would indicate a nearby point light source) or not (which would be simulating the physical impossibility of a light source both nearby and infinitely far away), and whether it’s rendering with actual perspective (without which it’s a cheap hack and physically impossible, but the difference is probably humanly indistinguishable, and honestly the whole thing is just a bit weird anyway given the orthographic top-down projection of the content, so maybe I shouldn’t even talk about the physical impossibility above).
    - burnedtoast 3y ago
      Yes the same goes for X-axis as well. Here's a screenshot showing that: https://pasteboard.co/O5H4djIUMoG6.png https://pasteboard.co/O5H4djIUMoG6.png
      - chrismorgan 3y ago
grishka 3y ago
That's why you ask your designer to give you an elevation value instead of a blur radius and offset. If you really want a shadow with arbitrary color/radius/offset like CSS box-shadow, you have to use paint.setShadowLayer() in a software-rendered canvas (a bitmap or a software layer). Exception is that such shadows for text can be rendered with hardware acceleration.
- burnedtoast 3y ago
  Yeah, that's normal practice and usually works OK. But then sometimes it happens that the given elevation value give a shadow much weaker than in the design tool. Especially for things like a bottom toolbar where the top of the shadow is close to the bottom of the screen and supposed to visually separate the toolbar from content. Another toolbar using the same elevation in another place on the screen may look fine. So when QA say that the shadow is too weak, you have to tell your designer this and they have to come up with something different, or you have to increase elevation to compensate, or fall back to a pre-rendered 9-patch, or something else... As i said, annoying :\

chrismorgan 3y ago

Can you show pictures or something of what you mean? I can’t find any mention of what you describe, and it would surprise me greatly to encounter a point light source rather than a distant light source, partly because of how fiendishly complicated it makes implementation (including just being impossible on the web), and partly just because we’re mostly used to distant light sources for illumination.

vesinisa 3y ago
I think they're referring to this: https://m2.material.io/design/environment/light-shadows.html https://m2.material.io/design/environment/light-shadows.html Notice how there are actually two shadows that must be combined. The point light source shadow rendering depends on the object position on screen.
- ghusbands 3y ago
  A point light source can be at infinity. I don't think that design document implies that shadows need to change based on screen position. Note that "elevation" is about how far 'off' the background the element is pretending to be.
- chrismorgan 3y ago
  They’re two shadows, but nothing calls them point sources; I claim that any reasonable implementer would from such descriptions absolutely presume them to be distant (as in, never have it even occur to them it might be otherwise). The only detail that seems confusing and could support otherwise is the sentence “On the web, shadows are depicted by manipulating the y-axis only.” (I’m using roughly SVG’s terminology: fePointLight has x, y and z, which can be approximately infinitely far away but it’ll only be approximately so, and feDistantLight, which has azimuth and elevation, and projects from infinity.)
burnedtoast 3y ago
https://pasteboard.co/AUrdZZe5KxoO.png https://pasteboard.co/AUrdZZe5KxoO.png In this screenshot all the views have the exact same spec: 8dp elevation.
- ghusbands 3y ago
  Do you see this in all apps or just custom/particular ones? Can you control where the key light is at all? It would be surprising for the key light to be so close to the screen (rather than nearer infinity), given that the design document linked elsewhere seems to expect consistency at particular elevations.
  - burnedtoast 3y ago
    It's the behavior for all apps and I don't think it can be customized. There are some APIs to affect the spot shadow color and ambient shadow color (from API 28), but no way to affect this offset / light source position AFAIK.
- chrismorgan 3y ago
  OK, now I’m interested in whether there’s any x-axis cast (which would indicate a nearby point light source) or not (which would be simulating the physical impossibility of a light source both nearby and infinitely far away), and whether it’s rendering with actual perspective (without which it’s a cheap hack and physically impossible, but the difference is probably humanly indistinguishable, and honestly the whole thing is just a bit weird anyway given the orthographic top-down projection of the content, so maybe I shouldn’t even talk about the physical impossibility above).
  - burnedtoast 3y ago
    Yes the same goes for X-axis as well. Here's a screenshot showing that: https://pasteboard.co/O5H4djIUMoG6.png https://pasteboard.co/O5H4djIUMoG6.png
    - chrismorgan 3y ago

grishka 3y ago

That's why you ask your designer to give you an elevation value instead of a blur radius and offset. If you really want a shadow with arbitrary color/radius/offset like CSS box-shadow, you have to use paint.setShadowLayer() in a software-rendered canvas (a bitmap or a software layer). Exception is that such shadows for text can be rendered with hardware acceleration.

burnedtoast 3y ago
Yeah, that's normal practice and usually works OK. But then sometimes it happens that the given elevation value give a shadow much weaker than in the design tool. Especially for things like a bottom toolbar where the top of the shadow is close to the bottom of the screen and supposed to visually separate the toolbar from content. Another toolbar using the same elevation in another place on the screen may look fine. So when QA say that the shadow is too weak, you have to tell your designer this and they have to come up with something different, or you have to increase elevation to compensate, or fall back to a pre-rendered 9-patch, or something else... As i said, annoying :\