[cairo] introducing a "context backend"

[Robert O'Callahan]

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]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cairographics.org/archives/cairo/attachments/20100423/1ba68a7f/attachment.html>