Re: Independent image loaders in gdk-pixbuf
- From: Havoc Pennington <hp redhat com>
- To: Matthias Clasen <maclas gmx de>
- Cc: gtk-devel-list gnome org, otaylor redhat com
- Subject: Re: Independent image loaders in gdk-pixbuf
- Date: 28 Sep 2002 13:33:09 -0400
Matthias Clasen <maclas gmx de> writes:
> I tried your struct approach instead, and settled on the following api:
>
> typedef struct _GdkPixbufFormatInfo GdkPixbufFormatInfo;
> struct _GdkPixbufFormatInfo {
> gchar *name;
> gchar *description;
> gchar **mime_types;
> gchar **extensions;
> gboolean is_writable;
> };
>
This should really be opaque, it seems likely we'd want to add fields.
> I'm willing to try this approach if the overhead of having two
> dlopenable objects per loader and always dlopening one per image format
> is not rejected beforehand.
That overhead makes me somewhat uncomfortable, though I guess we
should know exactly what the penalty is before rejecting out-of-hand.
I'm not sure I see the savings in having two dlopen objects (one
loaded always, one sometimes). Just one that's always loaded might not
be significantly higher-cost.
Perhaps the format magic could be in the text file (needed when most
apps start up to display their icons), but the FormatInfo requires a
dlopen (only needed in a file selector or the like)... really the
main place the overhead is a concern is for startup time.
Or we could allow some dlopen and some hardcoded modules, so we only
have to dlopen the librsvg FormatInfo thing, while FormatInfo is
built-in for most formats.
Havoc
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]