[cairo] surfaces and backends

[Vladimir Vukicevic]

I've been thinking about a cairo_surface_is_xlib()
cairo_surface_is_win32() API instead...  cairo_surface_get_type() has
the advantage of a small number of additional API entry points;
however, it also means that for anyone to implement a new surface
type, they have to do it inside cairo itself, including additions to
the enums.  This may not be a big deal, because right now the backend
interface isn't exposed so any surfaces end up needing to be in cairo
anyway; but it does change the method of adding a new surface type
from "add this .c and .h file to your build" to "add these files and
apply this patch".  It also means that cairo.h ends up having
backend-specific types/defines in there.

These may really be irrelevant issues; a cairo_surface_get_type()
returning an enum value will probably work just fine, especially since
I can't think of a concrete case where having this backend dependency
in the cairo front-end API will actually cause problems.

    - Vlad

On 2/24/06, Carl Worth <cworth at redhat.com> wrote:
> On Sat, 21 May 2005 11:01:22 -0400, Owen Taylor wrote:
> > What if we had:
> >
> > enum {
> >    CAIRO_IMAGE_SURFACE_TYPE,
> >    CAIRO_XLIB_SURFACE_TYPE,
> >    [...]
> >    CAIRO_FT_FONT_FACE_TYPE,
> > } CairoTypeID;
> >
> > CairoTypeID cairo_surface_get_type (cairo_surface_t *surface);
>
> As I commented a while ago on the bug report:
>
>         How do we identify surface types?
>         https://bugs.freedesktop.org/show_bug.cgi?id=2765
>
> I think this is the right basic style with which to tackle this
> problem. But I think I'd prefer separate enums for the various object
> types.
>
> And Robert's recent proposal to add a bunch of new cairo_xlib_surface
> functions made this seem more important to me. So here's a patch that
> adds the API I have in mind, (no implementation yet, but there's
> documentation here).
>
> This patch is already committed to the get-type branch in my personal
> tree if anyone wants to look at it.
>
> Some of the things to notice in the patch:
>
> * I had to choose a name for the pattern type created by create_rgb
>   and create_rgba. I consulted the language bindings guide and found
>   "solid". I went with that, and just added notes to the documentation
>   that solid means uniform color and might be opaque or translucent.
>
> * I created a single cairo_font_type_t that is used by both
>   cairo_font_face_get_type and cairo_scaled_font_get_type.
>
> * There is some inconsistency in the handling of type mismatches. I
>   documented what the current implementation does. I'm not sure that
>   we don't want to change the current behavior in some places, but
>   I'll follow up to Robert's message on that topic.
>
> Any likes or dislikes about the API should be made soon. I'll add an
> implementation shortly, and if I haven't heard any complaints, will
> push this out to the central tree after that.
>