Adds ability to turn off sdfs with paint. - #186020

After playing with this a bit though I'll say I'm not sure why anyone would want to disable sdfs with the current implementation. I thought there'd be a subtle artifact when tiling sdfs. I don't see one.

After playing with this a bit though I'll say I'm not sure why anyone would want to disable sdfs with the current implementation. I thought there'd be a subtle artifact when tiling sdfs. I don't see one.

Share your test code for that.

Here is the test code I used. It shows a clear difference in stitching with and without the checkbox on Skia. I don't have the code here to check the impact with SDF, though.

import 'dart:math';

import 'package:flutter/material.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        colorScheme: .fromSeed(seedColor: Colors.deepPurple),
      ),
      home: const MyHomePage(title: 'Flutter Demo Home Page'),
    );
  }
}

class MyHomePage extends StatefulWidget {
  const MyHomePage({super.key, required this.title});

  final String title;

  @override
  State<MyHomePage> createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  double turns = 0.0;
  bool useAA = true;

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        backgroundColor: Theme.of(context).colorScheme.inversePrimary,
        title: Text(widget.title),
      ),
      body: Center(
        child: Column(
          mainAxisAlignment: .center,
          children: [
            Transform.rotate(
              angle: turns * 2.0 * pi,
              child: CustomPaint(
                foregroundPainter: _MyPainter(useAA: useAA),
                size: Size(400, 400),
              ),
            ),
          ],
        ),
      ),
      bottomNavigationBar: BottomAppBar(
        child: Row(
          mainAxisAlignment: MainAxisAlignment.center,
          children: [
            Text('Rotate'),
            Slider(
              value: turns,
              onChanged: (value) {
                setState(() {
                  turns = value;
                });
              },
            ),
            Text('Use AA'),
            Checkbox(value: useAA, onChanged: (value) {
              setState(() {
                useAA = value!;
              });
            },)
          ],
        ),
      ),
    );
  }
}

class _MyPainter extends CustomPainter {
  _MyPainter({required this.useAA});

  final bool useAA;

  @override
  void paint(Canvas canvas, Size size) {
    Paint paint = Paint();
    paint.color = Colors.blue;
    paint.isAntiAlias = useAA;
    double w = size.width / 7.0;
    double h = size.height / 7.0;
    for (int ix = 0; ix < 7; ix++) {
      double x = ix * w;
      for (int iy = 0; iy < 7; iy++) {
        double y = iy * h;
        canvas.drawRect(Rect.fromLTWH(x, y, w, h), paint);
      }
    }
  }

  @override
  bool shouldRepaint(covariant CustomPainter oldDelegate) => true;
}

Golden file changes have been found for this pull request. Click here to view and triage (e.g. because this is an intentional change).

If you are still iterating on this change and are not ready to resolve the images on the Flutter Gold dashboard, consider marking this PR as a draft pull request above. You will still be able to view image results on the dashboard, commenting will be silenced, and the check will not try to resolve itself until marked ready for review.

For more guidance, visit Writing a golden file test for package:flutter.

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

Changes reported for pull request #186020 at sha 00b2ae9

So paint.isAntiAlias will disable using SDFs for the draw call, but it will still use MSAA anti aliasing? I think that's very unexpected based on the naming.

Should it disable all AA for the draw call, including MSAA? If we want something to disable SDFs but not disable MSAA, I think it should be through another mechanism rather than something misleadingly named "isAntiAlias".

So paint.isAntiAlias will disable using SDFs for the draw call, but it will still use MSAA anti aliasing? I think that's very unexpected based on the naming.

Should it disable all AA for the draw call, including MSAA? If we want something to disable SDFs but not disable MSAA, I think it should be through another mechanism rather than something misleadingly named "isAntiAlias".

One aspect of MSAA is that it does AA without stitching issues, so the most likely reason that someone might disable AA is covered. We could wait for a better hint or just do what this PR is doing for now and keep those more subtle questions on a burner.

One glitch is that we use MSAA (which stitches perfectly) up until we need to filter the output and then we have to resolve the MSAA samples - which makes them just "alpha coverage" on the partially covered pixels and thus has the same problems as computational AA/SDF. So, even our MSAA isn't perfect in all conditions for stitching.

Also, someone might want "whole pixel" granularity when they turn AA off. Do we have a more complicated hint that separates out "should it stitch?" and "how many samples per pixel do you want?".

But, until we have a lot of info on what developers might want, turning off the SDF and relying on MSAA is a good approximation with the implementation knobs and buttons that we currently have.

What Jim said (thanks). I'll add that MSAA is a screen-space anti-alias, whereas the SDFs are draw centric. Some it make sense to be effected by draw directions like this. That antialias option having no effect on MSAA is the status quo.