Skip to content

A Stack widget with children at different elevations renders in painting order for 2D but will not do so for "3D" #25673

@dnfield

Description

@dnfield

The following simple case:

Stack(
  children: <Widget>[
    Material(elevation: 5.0, color: Colors.red),
    Material(elevation: 1.0, color: Colors.blue),
  ],
);

will render a blue color by painting order (which is followed on Android and iOS), but a red color if elevation is respected (which seems to be the direction Fuchsia wants to take). This will cause confusing cross-platform inconsistencies that will be difficult for developers to test for - and could be particularly bad if a developer had sensitive information that was on the red square and expected it to be covered by the blue square until some other change was made. We should do something about it.

We should have some way to lint or assert if a stack's children have elevations that could cause what gets painted to be different on a 3d or 2d platform.

Ceratin pathological cases make it challenging:

  1. We don't currently have a good way to test the highest elevation of a child - and in fact, we might have a very confusing scenario where part of a child tree is higher than part of another child tree, but part of it is lower:
Stack(
  children: <Widget>[
    Material(elevation: 1.0, color: Colors.red, child: Stack(/* with more children that have different elevations */),
    Material(elevation: 1.0, color: Colors.blue, child: Stack(/* with  more children that have different elevations */),
  ],
);
  1. Elevation may be dynamically driven by an animation. A lint for this probably couldn't catch that, and an assert that covers this properly might not ever be triggered.

Another possibility is to re-define elevation as being based on painting order. In that case, the blue square would have an elevation of 1.0 on top of the red square's elevation of 5.0, giving it the potential to cast a shadow of 6.0 on something beneath the stack. That seems like a more complicated fix, but would probably be more consistent across platforms.

/cc @Hixie @goderbauer @tvolkert @jonahwilliams @zanderso

See https://github.com/flutter/flutter/pull/25670/files - specifically the changes made to the widgets there for some more context.

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions