[cairo] external backends

Ross McFarland rwmcfa1 at neces.com
Sun Aug 8 17:02:59 PDT 2004


On Sun, 2004-08-08 at 17:04, Jamey Sharp wrote:
> Well, it's easier to just install a separate header file. :-)

very much agree there.

> > 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.

that's the exact problem i ran into when i did the pdf backend a few
months ago. working with the current backend api wasn't ideal.

after putting a bit of thought into it i came to the conclusion (though
not very well thought through) that cairo might should be broken into
three pieces. the application api, the middleman, and the backend. the
app api would never change. the middle man could be the current stuff
between that api and the backends, or something else like pdf. and then
the backends would only be around when the current "middleman" was used.
as i said this hasn't been thought through or investigated any further
than brainstorming. i actually had two other messages to follow this
thread (one of which was going to discuss this and another was going to
re-present the colorspace discussion from a while back.) i figured it
best to take one at a time though.

-- 
-rm
http://www.neces.com/




More information about the cairo mailing list