@Hixie I recall you saying once that this was an intentional omission because dashed lines are slow? But then also that flutter/game had an implementation (or some example did?). Am I remembering correctly? Could you point me to that example? FYI @mit-mit

I implemented it on a circle for one of our demos (now the drag and drop manual test). We don't have generic path dashing because as you say, it's expensive to compute such paths. You can manually implement this by writing the code to manually draw the path dashed, but that'll be a lot of work, and thus feel expensive. Expensive things should look and feel expensive, so that people don't do them as much.

This is probably obvious question, as I do not see anything like that in the Flutter API, but let me ask to confirm: In Flutter, there is no classes for Android equivalent (or Android similar) role of PathEffect or it's extensions ComposePathEffect, CornerPathEffect, DashPathEffect, DiscretePathEffect, PathDashPathEffect, SumPathEffect, is that correct (at timepoint August 2017)? Thanks

@mzimmerm thanks for the questions!

That is correct at the moment. In due course we'll probably expose more and more such APIs, especially the fast ones.

@Hixie, Skia already has these effects implemented. Is the implementation less performant ?

Quite a shame that SkiaSharp has great coverage of Skia (a Google project) functionality available for C# (a Microsoft project), yet Flutter/Dart (a Google project) has almost nothing.

Just take a look at their API docs and compare that to Flutter and Skia
https://developer.xamarin.com/api/namespace/SkiaSharp/

https://developer.xamarin.com/api/type/SkiaSharp.SKPaint/
https://skia.org/user/api/SkPaint_Reference
https://docs.flutter.io/flutter/dart-ui/Paint-class.html

It's actually very intentional. We are being very careful in what we expose, so that using the API in the intuitive way will result in fast code where possible. We are being careful to make expensive APIs feel expensive.

This is a case where "less is more" is really true.

It's unbelivable there's no basic path operations in Flutter:

• Enumerate path (PathMetrics is good but for simpler operations why we should take those expensive)
• Create stroke outline from unclosed path
• Dash path
• Unclosed path intersecting

Could you please consider support those features.

Adapted @dnfield's example to a StadiumBorder, with an inset option (for my dashed-chip usecase)

import 'package:flutter/material.dart';
import 'package:path_drawing/path_drawing.dart';

class DashedStadiumBorder extends StadiumBorder {
  DashedStadiumBorder({
    this.inset = false,
    CircularIntervalList<double> dashArray,
    BorderSide side,
  })  : this.dashArray = dashArray ??
            CircularIntervalList<double>(
                <double>[4 * side.width, 2 * side.width]),
        super(side: side);

  DashedStadiumBorder.inset({
    this.dashArray,
    BorderSide side,
  })  : inset = true,
        super(side: side);

  final CircularIntervalList<double> dashArray;

  final bool inset;

  @override
  EdgeInsetsGeometry get dimensions {
    return EdgeInsets.all(inset ? 0.0 : side.width);
  }

  @override
  void paint(Canvas canvas, Rect rect, {TextDirection textDirection}) {
    switch (side.style) {
      case BorderStyle.none:
        break;
      case BorderStyle.solid:
        if (inset) {
          rect = rect.deflate(side.width);
        }
        final Radius radius = Radius.circular(rect.shortestSide / 2.0);
        final rrect = RRect.fromRectAndRadius(rect, radius);
        canvas.drawPath(
          dashPath(Path()..addRRect(rrect), dashArray: dashArray),
          side.toPaint(),
        );
    }
  }
}

I understand dashed lines as slow, but what are the options we have then? Not drawing a dashed line at all? Doesn't this goes against Flutter's own principle of:

Flutter helps deliver the original design vision, without loss of fidelity or compromises

If I go to my designer and say "Can you remake it without dashed lines? Our code doesn't support it", this just takes me back to native development where design compromises where a daily routine.

I honestly think flutter should support dashed lines, with big warnings on the docs. This is something very basic to any UI and shouldn't be a decision on the Framework level not to provide it, but our decision as devs to know when to avoid it. I have seen such warnings on the docs before.

In my particular case, I just need a straight dashed line to be shown once, dividing a Card in half. No animations, no nothing. I am pretty confident that it won't take any visible performance impacts, so I feel this decision should be mine, as I know my use case, and not from the Flutter team.

Thanks for listening.

@feinstein - is there some reason that you can't just use flutter_path_drawing?

The framework enables all you need to draw dashed lines at a pretty low level - in fact, flutter_path_drawing's code to do this is really only a few dozen lines of code wrapping that functionality.

The reason to not put the code in the framework itself is because it's something that is fairly expensive, and thus should be hard to do. For example, in the case of a straight dashed line shown once, you could create the path you want and get subsegments of it - or you could just pre-calculate it and draw only the paths you actually want on a canvas - or you could pre-calculate it using ColoredBoxes or Containers in a Row or Column or Stack or what-have-you.

I'm going to close this bug - I don't believe the framework will ever make it any easier to draw dashed lines (for reasons outlined in this bug). There is also a package available that helps you do it, which is maintained by a framework maintainer (which happens to be me! :)).

@dnfield you mean this package right? I am going to use it, it just felt weird that Flutter wouldn't support dashed lines natively as this is something pretty basic nowadays and I wanted to share my thoughts on this.

@feinstein Once in a while you find these strange things that all other languages/frameworks provide, but Dart and Flutter don't because they think developers shouldn't do it. It's an ideological barrier, so it's useless complaining. Dashed lines is one example. Another is to check if a Future is completed. You can't. Another is to be able to format your code with your own formatter. You also can't because they think you shouldn't. It's OK, Flutter is good, nothing is perfect.

@marcglasberg I feel like Apple telling me I am "holding it wrong" lol, but fortunately path_drawing makes this possible (although its a bit cumbersome/low level to use), but as long as it works its fine by me.

I agree with you that things can be frustrating sometimes, but then I remember how much more frustration I had in Java, so I start to feel better again.

BTW, dart provides an additional async library (2 parts blog post here explaining it) that many don't know about and there you can use ResultFuture which lets you ask if the Future already completed and get its value synchronously.

@feinstein I know that lib, but async/await returns a regular Future. Anyways.

This issue is about dashed lines, which is now possible (using Path.computeMetrics et al).
For other topics, please file separate issues. I'm not aware of anything preventing you from using your own formatter (indeed, the Flutter framework itself doesn't use dartfmt), but if there's something that would prevent it, we would want that filed as a bug so it could be fixed. Regarding Futures, if there's something you can't do because of the Future API, then again please file an issue so that we can make sure your use case is handled.

Commenting on this issue is unlikely to result in any changes since it is closed.

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.