API docs for Container.color should have a "troubleshooting" section that talks about "mysterious dividers"

[itsJoKr]

Steps to Reproduce

I have ListView with simple rows that have one Text, and BoxDecoration with the background color. When in the middle of scrolling, I can see dividers between rows. Not exactly dividers, but I can see through the list (confirmed by setting different background color).

Tested on iOS simulator and Android device.

Flutter Doctor

[✓] Flutter (Channel master, v0.1.6-pre.7, on Mac OS X 10.12.6 16G1212, locale en-US)
    • Flutter version 0.1.6-pre.7 at /Users/jokr/Documents/flutter/flutter
    • Framework revision c3bbcb6f91 (5 days ago), 2018-02-24 09:28:58 -0800
    • Engine revision ead227f118
    • Dart version 2.0.0-dev.28.0.flutter-0b4f01f759

[✓] Android toolchain - develop for Android devices (Android SDK 27.0.1)
    • Android SDK at /Users/jokr/Library/Android/sdk
    • Android NDK location not configured (optional; useful for native profiling support)
    • Platform android-27, build-tools 27.0.1
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-915-b08)

[✓] iOS toolchain - develop for iOS devices (Xcode 9.2)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 9.2, Build version 9C40b
    • ios-deploy 1.9.2
    • CocoaPods version 1.3.1

[✓] Android Studio (version 3.0)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-915-b08)

[✓] IntelliJ IDEA Community Edition (version 2017.2.5)
    • Flutter plugin version 21.2.2
    • Dart plugin version 172.4343.25

That is the normal case. But when scrolling I get this:

[cbracken]

/cc @Hixie @HansMuller for their thoughts

[HansMuller]

That's pretty strange: it's wrong but it looks sort-of attractive. Could you provide a small example that demos the problem?

[cbracken]

@Hixie suggests setting the background colour for the entire Drawer to the colour you're using for the list tiles. It's likely this is a result of sub-pixel anti-aliasing.

[itsJoKr]

@cbracken Yes, setting the background of the entire drawer "visually" fixes the issue, but there is still the issue.

@HansMuller Doesn't matter if it looks better. I didn't write anything in the code that should display dividers, and that's why this is the issue.

[itsJoKr]

I was able to reproduce this bug with very simple example:

var putThisIntoScaffoldBody = new ListView.builder(itemBuilder: (BuildContext context, int index) {
        return new Container(
          decoration: new BoxDecoration(color: Colors.black),
          height: 30.0,
        );
      }, itemCount: 30,
    );

Just put this widget into Scaffold body. On iOS I can see it when bouncing with the scroll. On Android, it's much easier to see it, you don't even need to scroll:

You can also see that not every divider is same width.

[HansMuller]

@HansMuller Doesn't matter if it looks better. I didn't write anything in the code that should display dividers, and that's why this is the issue.

Understood. That was just my attempt at humor.

[Hixie]

@itsJoKr Yeah, that most recent screenshot shows that this is indeed what we suspected. You're drawing a series of rectangles adjacent to each other, on top of a different background color, but they don't quite line up with the physical pixel boundaries. This means we try to antialias the edges, and each one is painted on top of the background, so the background shows up in the antialiasing. This is working as intended; it's how graphics works.

There's two basic ways to avoid this problem. The first is to do as suggested above -- if you want two adjacent boxes to have the same background and be adjacent, then draw the background once, e.g. by putting them into a single box with that background. The second is to wrap all those widgets with a RepaintBoundary, which will cause them to all be painted as one graphic which is then anti-aliased once with the parent. That might not solve the issue, depending on exactly what the alignment ends up being, but it should be better.

In general though the right answer is the first suggestion here; don't put two adjacent boxes with the same background color, just put the background color on the common background.

We should document this somewhere with diagrams to explain it better. Not sure where, maybe on Container.color?

[itsJoKr]

OK, I understand it now, thanks for the explanation.

[brianegan]

"In general though the right answer is the first suggestion here; don't put two adjacent boxes with the same background color, just put the background color on the common background."

Is this always a viable solution? For example, I want my appBar to have the same background color as the first widget in the body of a Scaffold, but the rest needs to be a white BG.

I've also fixed this by moving from a bottom padding of 5.0 to a SizedBox of 5.0 and it "Fixed" the problem, but felt a bit weird. The solution you propose sounds like creating a Stack with a Container + BG for the top part and a Scaffold for the rest.

Would be cool if padding "Just Worked" for this use case

[itsJoKr]

My problem here is the line: "This is working as intended; it's how graphics works." Because I'm pretty sure I wouldn't see this issue in Android and iOS native.

[SteveAlexander]

For a specific artistic layout I was having this "mystery thin divider" problems with, I wrote the following:

class PixelRatioDivider {
  double quantizedUnit;
  double remainder;

  PixelRatioDivider(BuildContext context, pixels, divideBy) {
    final pixelRatio = MediaQuery.of(context).devicePixelRatio;
    quantizedUnit = (pixels * pixelRatio ~/ divideBy) / pixelRatio;
    remainder = pixels - (quantizedUnit * divideBy);
  }
}

Using whole multiples of the quantizedUnit, and filling in with the remainder, I was able to make my Mondriaan-esque layout work seamlessly.

[Hixie]

See also #17084

[goderbauer]

Closing this as dupe of #17084.

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.