with the display

Technically with the raster buffer, which isn't necessarily the screen if there's a rotation or perspective transform between the current raster buffer and the screen.

fixed

You need to call saveLayer before you establish the clip

That's what I had at first but I couldn't understand it. Surely if the clip is inside the layer, it's the problem all over again (it has to apply the clip to each drawn shape)? And if the clip is outside the layer, then when it comes time to place the inner layer into the outer layer, then it applies the clip all at once, as described here?

I think the mental model is that that the clip is applied when you call restore(). Specifically, it's part of the pipeline of transformations (e.g., filters, clips, blends, etc) that is applied to the temporary buffer as it is copied into the parent buffer. Conceptually, it would probably make more sense to combine the call with the saveLayer call, as the filters and blends are, but that's not how the Skia API is set up.

but if that's the case, shouldn't that mean you don't get the problem ever? Is it just clips that are at the start of the display list that work out, and clips later in the display list are hosed? Or?

I don't understand why "draw clip draw draw" would fail but "clip draw draw" would not. why are the two clips in "clip draw clip draw" handled differently?

I'd recommend either experimenting with https://fiddle.skia.org/ or asking the Skia team.

This paints a clean white rounded rect:

  void paint(Canvas canvas, Size size) {
    Rect rect = Offset.zero & size;
    canvas.clipRRect(new RRect.fromRectXY(rect, 130.0, 130.0));
    canvas.saveLayer(rect, new Paint());
    canvas.drawPaint(new Paint()..color = Colors.red);
    canvas.drawPaint(new Paint()..color = Colors.white);
    canvas.restore();
  }

This paints a white rounded rect with a red outline:

  void paint(Canvas canvas, Size size) {
    Rect rect = Offset.zero & size;
    canvas.saveLayer(rect, new Paint());
    canvas.clipRRect(new RRect.fromRectXY(rect, 130.0, 130.0));
    canvas.drawPaint(new Paint()..color = Colors.red);
    canvas.drawPaint(new Paint()..color = Colors.white);
    canvas.restore();
  }

Oh my. Sounds like I've misunderstood how this API works. You might want to check call sites like https://github.com/flutter/flutter/blob/master/packages/flutter/lib/src/rendering/object.dart#L358 and https://github.com/flutter/engine/blob/master/flow/layers/clip_rrect_layer.cc#L50 which sound like they're wrong.

Does that work? I would have expected Skia not to produce correct results for an RRect clip without a save layer even if you only have one draw operation. You're correct that Skia could optimize that case to work, but I don't think they implement that optimization.

I haven't tested it, but what could it do other than the right behaviour?

My money is on a rectangular clip that's the bounding box of the path.

This paints a clean white rounded rect in a green area:

  void paint(Canvas canvas, Size size) {
    Rect rect = Offset.zero & size;
    canvas.save();
    canvas.drawPaint(new Paint()..color = Colors.green);
    canvas.clipRRect(new RRect.fromRectXY(rect, 130.0, 130.0));
    canvas.drawPaint(new Paint()..color = Colors.white);
    canvas.restore();
  }

I'd say "relatively expensive" rather than "very expensive". I think that's the terminology we've used elsewhere to describe this cost (e.g., in https://docs.flutter.io/flutter/widgets/Opacity-class.html).

done

s/effectively/can/

I'm not sure this sentence is true. I'm sure there are more expensive operations that we expose (or will eventually expose), such as convolution image filters.

removed