Shadows depend on internal canvas state

[yjbanov]

Steps to Reproduce

flutter run the following Flutter app:

Sample app

import 'dart:ui';
import 'package:vector_math/vector_math_64.dart';

const Color _kShadowColor = Color.fromARGB(255, 255, 0, 0);
final Path shadowPath = Path()..addRect(const Rect.fromLTRB(0, 0, 20, 20));

Future<void> main() async {
  window.onDrawFrame = () {
    final SceneBuilder builder = SceneBuilder();

    void _paintPicture(Rect bounds, void Function(Canvas) painter) {
      final PictureRecorder recorder = PictureRecorder();
      painter(Canvas(recorder, bounds));
      builder.addPicture(Offset.zero, recorder.endRecording());
    }

    void _paintOutline() {
      _paintPicture(Rect.largest, (Canvas canvas) {
        canvas.drawRect(
          const Rect.fromLTRB(0.0, 0.0, 20.0, 20.0),
          Paint()
            ..color = const Color.fromARGB(255, 0, 0, 255)
            ..style = PaintingStyle.stroke
            ..strokeWidth = 1.0,
        );
      });
    }

    void _paintPhysicalShapeShadow(double elevation, Offset offset) {
      builder.pushOffset(offset.dx, offset.dy);
      builder.pushPhysicalShape(
        path: shadowPath,
        elevation: elevation,
        shadowColor: _kShadowColor,
        color: const Color.fromARGB(0, 0, 0, 0),
      );
      _paintOutline();
      builder.pop(); // physical shape
      builder.pop(); // offset
    }

    void _paintBitmapCanvasShadow(double elevation, Offset offset) {
      builder.pushOffset(offset.dx, offset.dy);
      _paintPicture(Rect.largest, (Canvas canvas) {
        canvas.drawShadow(
          shadowPath,
          _kShadowColor,
          elevation,
          true,
        );
      });
      _paintOutline();
      builder.pop(); // offset
    }

    _paintPicture(Rect.largest, (Canvas canvas) {
      canvas.drawColor(const Color.fromARGB(255, 255, 255, 255), BlendMode.color);
    });

    builder.pushTransform(Matrix4.diagonal3Values(5, 5, 1).storage);
    builder.pushOffset(10, 40);

    for (int i = 0; i < 7; i++) {
      _paintPhysicalShapeShadow(i.toDouble(), Offset(40.0 * i, 0));
    }

    for (int i = 0; i < 7; i++) {
      _paintBitmapCanvasShadow(i.toDouble(), Offset(40.0 * i, 80));
    }

    for (int i = 0; i < 7; i++) {
      _paintPhysicalShapeShadow(i.toDouble(), Offset(40.0 * i, 160));
    }

    builder.pushOffset(0.0, 240.0);
    _paintPicture(Rect.largest, (Canvas canvas) {
      for (int i = 0; i < 7; i++) {
        canvas.drawShadow(
          shadowPath,
          _kShadowColor,
          i.toDouble(),
          true,
        );
        canvas.drawRect(
          const Rect.fromLTRB(0.0, 0.0, 20.0, 20.0),
          Paint()
            ..color = const Color.fromARGB(255, 0, 0, 255)
            ..style = PaintingStyle.stroke
            ..strokeWidth = 1.0,
        );
        canvas.translate(40.0, 0);
      }
    });
    builder.pop(); // offset

    builder.pop();
    builder.pop();
    window.render(builder.build());
  };
  window.scheduleFrame();
}

Expected results:

The shadows in each column should be identical.

Actual results:

The shadows are different.

This is observable as of 3cee8e0

[yjbanov]

The theory is: the shadow depends on the state of the canvas we draw on, in addition to the shadow parameters that are passed (color, path, elevation). It seems the shadow is pushed away from the (0, 0) coordinate along the X axis. Because the second row uses one canvas per shadow the X offset stays the same. However, the fourth row draws multiple shadows in one wide canvas. Notice how the right-most shadow is pushed to the right.

Big thanks to @DaveShuckerow for discovering this!

Note, this bug does not affect the Web (the Web has other issues, but not this one).

/cc @chinmaygarde

[yjbanov]

@chinmaygarde @cbracken I did not assign a milestone to this. Feel free to triage a you see fit. I speculatively added dependency on Skia because my investigation of this bottomed out at a call to the Skia API (third_party/skia/include/utils/SkShadowUtils.h). I'll focus on fixing web shadows (#32215).

[creativecreatorormaybenot]

@yjbanov Is this not the same behavior I alluded to in #48027? It is obvious that the shadow depends on the canvas' state because this will determine where the light source is positioned relative to the shadow.

Btw, I depend on this behavior in creativecreatorormaybenot/clock. In particular, here: L802

Went a bit more in-depth here.

[rydmike]

@yjbanov I'm happy to see this issue noticed and recorded. I had planned to raise it too, but now I will just add my 0.05$ worth of input to it.

TLDR

I think the behavior reported here is caused by the imaginary light source placement used in the Material Elevation design to cast shadows.
The Material team does beautiful designs, but it looks to me like either the design or the Flutter implementation does not properly consider the impact of the current used implementation on larger surfaces. The current implementation looks very poor on larger surfaces.

---

The imaginary light source for Material Elevation shadows clearly places the light source above the upper left corner of the surface. In my opinion, at least in the Flutter implementation, this light source location is too low down (z axis wise from the surface). This causes the elevation shadows to become very deep on the bottom and right side of elements, as the surface area grows and elements with elevation shadows are placed close to the bottom or right edge of the surface area.

Below are some examples to demonstrate the issue.

The screenshots below were rendered with Flutter 1.15.4-pre.107 channel master on Windows Desktop, but the same effect can be seen already when using large Android/iOS Tablet devices. The desktop usage just makes it possible too resize and easily show the issue. Also, never mind the content on the screenshots, it is just from an experimental version of a test/dev application’s Settings screen that has Material Card panels and other elevation using elements and it is responsive and show current screen size. Very practical for demonstrating this issue. I noticed this issue in June 2019 and it has remained unchanged since.

All the settings panels below are Material Cards in the screenshots and use the same Material Elevation 3. The demonstrated differences in the shadows depend on their location on the screen, in relation to the imaginary light source.

On small devices, phones and small tablets, the reported surface pixel size is quite small, so the deeper shadows towards the bottom of the screen or the right edge, is barely visible and very subtle.

Size iPhone5
For example, on a small device like an iPhone5 that reports 320x568 pixels, everything looks fine, even though the higher elevation towards the bottom can noticed if you look really closely, the effect is still fine and subtle, probably like intended.

Size iPhone Xs Max
On new and much larger phones, like iPhoneXs Max that reports 414x896 pixels, it is more obvious already towards the bottom of the screen.

Size iPad Pro 12.9
When we move up in surface size to what is probably the largest current device, the 12.9” iPad Pro that reports 1366x1024 pixels, the differences in shadow depths become obvious and already don’t look so nice anymore.

In the next picture the drawer is closed on same iPad size, just to show that the shadow sizes are the same as in the previous images on the edges, demonstrating that that shadow depth is, as it should be, dependent only on the physical location of the element with a shadow on the screen and not of the layout area where it is placed, which would not work if we want location based shadows.

Ref: iPhone pixel sizes
iPad pixel sizes

Size full HD - Desktop/Web
As we move up in size to the most common desktop/web size, full HD 1920x1080 pixels. The Material Elevation shadows towards the bottom and right edge are already so pronounced that using them can no longer be recommended.

Size 4k
If we go up to 4k resolution, then the Material Elevation shadows start look utterly ridiculous. Sure, my automatic responsive application layout is beginning too look silly at this size too, but that is another topic. 😊
I threw in a Theme Details panel on this large layout too, just to show that this issue affects all widgets that use Material Elevation for shadows, not just the Material Card.

---

I hope any of this is useful input and that elevation shadows in Flutter for larger surfaces can be improved.

I think this might be something that needs to be looked over together with the Material design team. Maybe they have already considered how shadows should look and behave on larger surfaces, maybe not, but at least it is clear that Flutter’s implementation of how shadows behave on larger surfaces does not look so nice now and I honestly doubt the Material design team intended it to look this way on larger surfaces.

---

FINALLY
It is worth noticing that this shadow issue only affects Material Elevations, if you create a custom shadow using using BoxShadow you will not have this issue. However, as a lot of widgets depends on elevation for their shadow the impact is rather wide spread. I think the solution is just to move the imaginary light source proportionally higher up as the surface area grows, in order to keep a more subtle effect on the depth of the shadows for larger surfaces, while keeping it still detectable/visible on smaller surfaces too, if that is the design intent.

The HTML/WEB shadow issue in 32215 also affects how custom BoxShadows look on web and they differ significantly from the Andorid/iOS/MacOS/Win look. There it is probably a difference in the shadow rendering implementation. Since elevation shadows in Flutter probably uses the same primitives to draw shadows as BoxShadow (I tried to check, but the rabbit hole was too deep for me) the look of material elevation shadows on large Web desktop layouts might be affected by both issues.

[yjbanov]

/cc @liyuqian - related to our discussion yesterday

[liyuqian]

@jvanverth is the Skia expert on shadows I believe. He may have some insights on why this happened.

[jvanverth]

Those results seem expected to me -- with the DrawShadow call, the light position and radius is not affected by the matrix, so as the paths get farther and farther away from it, the more shadowing you get. This look is consistent with what you'd get from Android. That said, it should be possible to get a more orthographic look with DrawShadow by locking the light position to the path in some way.

[creativecreatorormaybenot]

That is what I said as well 😕

[rydmike]

Thanks for looking into this.
A considerably more orthographic look is certainly needed, probably there are different ways of achieving it, higher light position plus wider light radius or by moving the light position along the path.

Yes the elevation shadows look is the same on all Skia using implementations (Win, Linux, Mac, iOS, Android, Fuchsia ?). It is just that on typical small handheld devices, the drawing surface is so small that it is less of an issue on them, people tend not to notice it as much, although it is clearly visible already on large modern phones. Increased desktop and large tablet usage is clearly making this issue more obvious now.

Just as another example here are two fresh comparison screenshots, using the Skia (from Win Desktop in this case) rendering and Web (apparently with the fix, applied) implementation, both screenshots were made with Flutter master: Flutter 1.15.19-pre.7

Desktop/Skia

Web

The fix flutter/engine#16963 for Web that fixed the too large and fuzzy shadows on WEB, also made the WEB elevation shadows look fairly close to when an element is close enough to the upper left corner in the Skia implementation. The WEB implementation does not show the same kind of light source behavior as the Skia implementation. The WEB elevation shadows now actually look much better on large surfaces than the Skia variant does, so that is nice progress! 👍

One could of course argue and discuss what the actual design intent is? How should it look according to Material design? Still I cannot really think that the Material design team would condone the current look we currently get with elevations when using the Skia implementation. It effects all elements that use elevation shadows and the current implementation makes all elevations on larger surfaces, when the element is far right or low down, look... well to be a bit blunt, utterly ridiculous! So I seriously doubt it is intended to look like this. Modern Material design is after all quite tasteful! 😃 Still, please do discuss it with the Materiel design team too. How should it really look? As we are aiming for desktop use too, the design needs to work and be tested all they up to at least 8k resolution.