CustomMarker add_path and get_compiled_path likely to fail on some backends

[corranwebster]

This issue could alternatively be "Compiled Path API inconsistent between backends".

The issue here is that both of these methods on CustomMarker try to provide a copy of the custom marker's path scaled appropriately for the size of the marker. This relies on a call to CompiledPath.scale_ctm which is not available on all backends (eg. QPainter backend, celiagg backend) and in some cases (eg. QPainter) there doesn't look to be an easy way to provide that support.

As a result the call will fail.

In some cases add_path may still work in use because it is being used by passing in a GC instead of a path.

[jwiggins]

I don't think CompiledPath has any reason to contain a transformation matrix.

That said, I think this should give the same result across backends:

from math import pi
with gc:
    gc.set_line_width(7)
    gc.set_stroke_color((1.0, 0.0, 1.0, 1.0))

    with gc:
        gc.translate_ctm(50, 50)
        for i in range(0, 12):
            gc.translate_ctm(20, 0)
            gc.rotate_ctm(2*pi/12.0)
            gc.move_to(0, 0)
            gc.line_to(20, 0)
        gc.stroke_path()

That is, when you're modifying the implicit path in a GraphicsContext the current transformation matrix is absolutely relevant. But kiva.agg can't have nice things (#390) because it does path transformation too early.

I don't think this necessarily precludes AbstractMarker.add_to_path from scaling markers.

[jwiggins]

Right. I played around with this a bit in celiagg... I don't think it's actually possible to do this for the implicit path. We could possibly add it to CompiledPath, but even that might be too confusing.

Based on the intractability of #390 for kiva.agg, I see this as a design bug in kiva.agg. We should refactor AbstractMarker so that it works with backends which implement transformation correctly.