[prev in list] [next in list] [prev in thread] [next in thread]
List: gtk-devel
Subject: Re: Independent image loaders in gdk-pixbuf
From: Havoc Pennington <hp () redhat ! com>
Date: 2002-09-28 17:33:09
[Download RAW message or body]
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
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic