Re: Independent image loaders in gdk-pixbuf



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]