Re: [PATCH] speed up stock icon registration (was: Improving Nautilus startup time)

Am Freitag, den 10.03.2006, 10:34 +0100 schrieb Alexander Larsson:
> On Thu, 2006-03-09 at 16:26 -0500, Matthias Clasen wrote:
> > On 3/9/06, Christian Neumair <chris gnome-de org> wrote:
> > >
> > > The attached patch ensures that we don't hardcode any pixels/icon sizes
> > > and don't lookup any stock icons during icon registration, but just add
> > > all the stock icon names we need to the factory. Measuring with a GTimer
> > > I could reduce the icon registration to rougly 1/4 of the former time,
> > > mostly because the gtk_icon_theme_lookup_icon calls are quite expensive.
> > > I don't know whether it buys us much to delay the icon size lookups
> > > until they're actually needed, but the Nautilus startup feels
> > > significantly faster with the patch applied.
> > >
> > 
> > It would be good to understand what this particular nautilus code is trying
> > to achieve in the first place. Why does it need to manually register
> > icon sources ?
> I believe its because we want to use named icons in the menus. And that
> doesn't work without registering them first. (If i remember correctly)

Yes, that is right. "named icons" in this case means GTK+ stock icons.
The code registers the icon names from the GtkIconTheme (as of
gtk_icon_theme_lookup_icon) as stock icons, because GtkActions have a
"stock-id" attribute, but you can't set their "icon-name".

We could also set "stock-id" to NULL, connect a handler to the
"connect-proxy" signal and manually lookup each of the icons from the
icon theme ourselves.

Maybe GtkActions should also have an "icon-name" property, which would
call set_icon_name on the proxy widgets.

Note that as soon as the first windows is realized, (which happens in
nautilus_application_create_desktop_windows, if a desktop window is
displayed), the icon cache will be created anyway, so Behdad'd work is
way more important here than this patch. But at least it saves us some
icon theme lookups. Note that if the stock lookup later fails, a warning
will be issued, and a broken image will be displayed, but considering
that Nautilus depends on the GNOME stack and the "gnome-" icon family is
distributed in gnome-icon-theme, this shouldn't be a problem.
If it is considered a problem (Alex?) we can still do what I proposed
above, i.e connect to "connect-proxy".

I couldn't figure out why each of the sizes is registered separately,
and why this order was picked. The GtkIconFactory will use
render_icon_name_pixbuf, which will in turn ask
gtk_icon_theme_load_icon. From reading gtkicontheme.c:theme_subdir_load
and gtkicontheme.c:insert_theme, it looks like the themes are themselves
able to determine whether precisely matching non-scaled icons (i.e.
PNGs) will be preferred over scaled icons (SVGs), by setting the desired
order in the "Directories" key of their icon.theme file. So just using
an icon source with the icon name for each of the icons should work.

Christian Neumair <chris gnome-de org>

Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]