For cairo backends that wrap high-level drawing APIs like Quartz and D2D, exposing the platform API as a surface backend isn't a very good fit. An ID2D1RenderTarget and a CGContext are much more like a cairo context than a cairo surface: for example, they have a CTM. For efficiency, we would like to avoid buffering path data in a cairo_path_fixed_t and converting to native path data in a separate pass --- avoiding conversion from double to cairo_fixed_t and back to double; this suggests we need some kind of native path object stored in the cairo_t. (For optimal performance with Quartz, we would want to be emitting the path directly into a CGContext.) Our cairo_retained_path_t API lets us avoid this overhead in some cases, but in others (e.g. existing scripts that use <canvas> to render paths over and over again) reducing the cairo overhead of immediate path filling and stroking is essential. How would people feel about introducing some kind of "context backend" that lets pretty much all of the functionality of a cairo_t be passed straight through to a platform context backend? Rob -- "He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]