[cairo] support for external surface backends

[Sebastian Reichel]

On Wed, Jul 10, 2013 at 04:21:24PM -0500, Matt Sealey wrote:
> I never saw any plans but I'd be pleased to suggest a route to doing
> it. I think cairo should support loadable backends - it would go to
> solve this problem and also to mitigate the strange features that if
> you compile in a backend to libcairo suddenly you end up with shared
> dependencies. Any app wanting to use simple image surfaces or xlib
> surfaces on a system with cairo compiled to use GLES suddenly then is
> implicitly linked to GLES, EGL (maybe VG) and so on, which is rather
> an odd circumstance (the net effect is that on the Ubuntu systems I
> run, for example, building Cairo to use GLES means the entire GLES
> stack ends up in the initramfs because of Plymouth's dependency on
> libcairo - but Plymouth doesn't use Cairo EGL or GLES backends)
> 
> I don't advocate making externally developed backends available,
> though, that requires fixing down a surface API and exposing it.

Well there is already a surface API, which is used internally.
I can understand you don't want to declare it as a stable API,
since it obviously makes your life harder :)

Maybe a compromise solution would be ok: Just expose the API
as private, e.g. /usr/include/cairo/private/surface.h
Thus it can be used by external software, but you explicitly
do not gurantee it's stability.

If did not miss anything in the git logs the internal surface
API has been mainly enhanced for multiple years, so I don't
think external backends would break often using this approach.

The only remaining problem using this approach is
cairo_surface_type_t.

> Having a patch which integrates your backend then building Cairo for
> yourself should suffice, though.

Yes forking cairo is a solution I can do already (even without
loadable backends). But it's a very cumbersome solution if I want
to distribute the backend to others.

I think just having cairo's currently built-in backends in their own
shared object does not help in my case. It's just the first step.

> What should happen is when you try and create a surface, cairo
> knows which backend to load at that point, loads it (and pulls in
> dependencies if it's using dlopen) and then the backend will work
> - or not. In the case it does not load, cairo can essentially fail
> creating a surface on that backend.

This would imply, that there's a stub for each backend in the main
cairo library. For me it seems much simpler and cleaner, to put
the whole backend into a shared library and link appropriately.
For example if a software needs cairo + svg backend it links against
-lcairo and -lcairo-svg (pkg-config --libs cairo cairo-svg).

> [...]
> Someone would need to map out the interdependency of initializing a
> backend and what might be missing in the indirect functions associated
> with it that need to be split.

It should be possible to do this backend-by-backend, which makes the
task easier.

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.cairographics.org/archives/cairo/attachments/20130712/bbcde617/attachment.pgp>