Technically, while SK_Color constants are automatically interchangeable with DlColor instances (they both just boil down to a uint32_t), It would be better to use DlColor::kTransparent() here to continue the theme of non-skia use while talking to Dl objects.

Is there a need to add these files to the display_list code? The mechanism is only used by one "client" module of DL and isn't generally something that developers query about their display lists. I provided the general utilities in this package (such as the Ignore classes) to help with implementing OpReceiver classes, with the intention that other modules or packages could roll their own for their own purposes.

For example, Impeller processes OpReceiver streams using a class that lives in their source hierarchy.

I initially put it in the platform/embedder/ but saw canvas_spy is in /common, so I thought maybe this class should be in a common place.

Do you have a preference where it should be?

Why is this needed? I'm guessing if the spy stuff gets moved out of here into the embedder source directories then it doesn't need to be added here, but I would have thought that you could implement an OpReceiver without having to add this dependency...?

This is for the unittest, to generate a concrete DlImage for testing.

I've been using lower case for getters which I think is compliant with the style guidelines - did_draw()...

What if source is null?

p0 == p1 draws something

I'm not sure about elevation == 0. I think it might also depend on transparent_occluder as well.

what does transparent_occluder do?

Does this compile without inheriting from IgnoreDraw? I think you probably cover all of the draw commands yourself.

There are still calls in ignoreDraw: save, savelayer, restore.

This could also be deduced from display_list_ being non-null or builder_ being null.

If this method is called more than once it will repeat the op_spy operation. Also, it will re-use the op_spy object which means the second answer might not be correct. I would change this so that it only does the spy operation once and remembers the answer.

Also, you don't need to permanently store an op_spy object, just create one on the fly when you need to compute the answer and remove the dl_op_spy field from the object.

You only need dl_op_spy for the short time when you are computing the answer. It can be created on the stack in that method.

dispatching => dispatch

I don't think you want to ignore any Draw calls, I'd remove the IgnoreDraw inheritance to make sure you've implemented all of them.

Also, since you are intending for DlOpSpy to implement DlOpReceiver, that should be your first public inheritance even though you get it indirectly from any or all of the Ignore classes you inherit from - it's good to explicitly document that this class is first and foremost intending to be a Receiver (and the rest of the inheritance clauses are just implementation details).

So:

class DlOpSpy final : public DlOpReceiver,
                      public IgnoreAttributeDispatchHelper,
                      public IgnoreClipDispatchHelper,
                      public IgnoreTransformDispatchHelper {

And if this works without the public inheritance from the Ignore classes that might indicate the purpose even better, as in:

class DlOpSpy final : public DlOpReceiver,
                      IgnoreAttributeDispatchHelper,
                      IgnoreClipDispatchHelper,
                      IgnoreTransformDispatchHelper {

(I realize we aren't consistent about this in other places, but we probably should be)

Perhaps simplify the comment to

"Indicates if the attributes are set to values that will modify the destination. For now, the test only checks if there is a non-transparent color set."

and maybe change the name to "will_draw_"?

This test seems out of place compared to the other draw methods. If some complicated operation on path was being saved, then it might make sense, but is there a reason why it doesn't just use did_draw_ |= dirty_ like the rest?

Same as with drawPath, is this saving enough work to justify an early return? This method is very much like drawColor and should have a similar implementation.

This could also be std::optional<bool>?