Re: GdkPixbuf vs. Cairo, new image library needed?

["Kalle Vahlman" <kalle vahlman gmail com>]

2007/10/13, BJörn Lindqvist <bjourne gmail com>:
> On 10/8/07, Kalle Vahlman <kalle vahlman gmail com> wrote:
> > 2007/10/8, BJörn Lindqvist <bjourne gmail com>:
> > > It feels like Cairo doesn't fit in. For example, GDK uses GdkColor to
> > > represent colors but Cairo has no equivalent.
> >
> > There is gdk_cairo_set_source_color() though, which bridges the gap.
> >
> > > Same thing with
> > > GdkRectangle, GdkPoint and a whole host of other types that becomes
> > > much less useful in a cairo-world.
> >
> > There's also gdk_cairo_rectangle() and _region(), and I'm sure the
> > rest (what they ever may be) could have similar bridging API if deemed
> > necessary. Like forming a path from an array of GdkPoints etc.
>
> Yeah, but those functions aren't substitutes for "native" Cairo
> types. For example, gdk_cairo_set_source_color() as no matching
> gdk_cairo_get_source_color(). It is not so strange because Cairo
> handles an infinite amount of colors in the range 0..1 and has alpha
> channels, GdkColor only has 0..65535 and no alpha channel.

This is very easy to explain, since cairo itself doesn't have API to
do that. The set_rgb* functions are just shorthands for creating an
infinite single color plane as the source pattern. The API would not
make much sense either, what would it return if the source is a
surface? Or a gradient pattern?

> There is a
> similar mismatch between GdkRectangle and cairo_rectangle_t.

So are you suggesting GDK should operate in subpixel precision or that
cairo would reduce it's precision? Either one sounds like a bad idea
to me.

> I think that integrating Cairo with GDK involves much more work than
> just replacing GdkPixbuf even if that is good first step.

I think it's more a question of how much integration is worth the
trouble, GDK and cairo have totally different targets and thus totally
different API.

> > Even having an additional API for things like
> > gdk_pixbuf_cairo_load_from_file() would be a step forward I guess. I'd
> > personally like to see all the useful pixbuf API (file loading/saving,
> > possibly others) migrated to allow cairo usage and then deprecate
> > PixBufs over cairo image surfaces, but YMMV.
>
> I think that is out of the question. The Cairo developers are happy
> with Cairo being "only" a drawing API and letting other libraries
> handle loading and saving.

I'm quite aware of that, and I wasn't suggesting making cairo load
anything. I was suggesting that gdk-pixbuf would get API to load into
cairo surfaces in addition to pixbufs, adding other useful bits of API
that pixbufs have and cairo surfaces don't and then marking pixbufs as
deprecated.

-- 
Kalle Vahlman, zuh iki fi
Powered by http://movial.fi
Interesting stuff at http://syslog.movial.fi