[cairo] external backends

[Jamey Sharp]

On Sun, Aug 08, 2004 at 03:31:50PM -0400, Ross McFarland wrote:
> <snip>
> it is impossible to create backends outside of the cairo build process.

I agree that it would be a useful thing to do.

> perhaps a mechanism could be employed to selectively expose the
> necessary api (something like #define _CAIRO_BACKEND_API_) while still
> keeping it well hidden from apps.

Well, it's easier to just install a separate header file. :-)

> several things stand in the way. for starters cairoint.h (internals, not
> int) and cairo_wideint.h are not installed, but are required by
> backends. secondly the api requirements of a backend aren't met. part of
> the missing api is hidden with preprocessor tricks and the other portion
> aren't exported symbols.

In other words, some API needs to be designed. This API needs to be the
minimal set of declarations needed to create an external backend.

> in the long run i would envision cairo's core becoming rather stable and
> development on it slowing. i don't see this being the case as much for
> backends. i would imagine there will always be new situations required
> new backends or at least changes to existing backends.

That's the problem.

If you're willing to always work in terms of giant images or lists of
trapezoids, then the current interface between the Cairo core and the
backends is good enough. Somebody could move a few functions from the
current non-installed headers to a new installed header, and then the
backends could be pulled out of the library.

But to efficiently implement a Cairo backend, it makes a lot of sense to
hook at higher semantic levels. For example, a PDF backend could
transform cairo_move_to, cairo_line_to, and cairo_stroke calls directly
into the equivalent PDF commands. (There may be reasons to not do this,
but I needed an example.)

So it's hard to design an API that's flexible enough to allow efficient
implementation, and as a result keeping the backends inside the main
Cairo library has seemed like the best idea so far.

I could see a multi-level backend API making some sense, perhaps. The
existing images/trapezoids interface would be a low-level API, but as
uses are found for higher-level hooks, new backend APIs can be added.
-- 
Jamey Sharp <jamey at minilop.net> - http://minilop.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/cairo/attachments/20040808/66f7935a/attachment.pgp