[Nautilus-list] Re: SVG icons
- From: Alex Larsson <alexl redhat com>
- To: Darin Adler <darin bentspoon com>
- Cc: nautilus-list eazel com
- Subject: [Nautilus-list] Re: SVG icons
- Date: Mon, 25 Feb 2002 12:44:20 -0500 (EST)
On Mon, 25 Feb 2002, Darin Adler wrote:
> On 2/25/02 8:39 AM, "Alex Larsson" <alexl redhat com> wrote:
>
> > Yeah. How would you make them larger?
>
> Well, I guess that's not allowed. I'm thinking the concept is that you have
> a certain size "field" for an icon, and you want to be able to do whatever
> you want inside that field.
Yes. That would be possible with my patch (i believe).
> Can we do something better here? With the PNG files and such, I wanted a
> nice way to allow the icon designer complete flexibility. And I don't see
> why it can't be the same way with SVG files. A problem is that in either
> case we don't want to render some huge icon and scale it down in memory.
>
> I'm really mixed up about the state of this right now.
It was a while since I worked with the icon factory, so let me try to
grasp what is happening here.
With bitmapped icons it works like this:
Nominal size for icons is 48x48, and if you want to have specific icons
for other zoom levels you need to call them something like myicon-72.png.
When an icon is requested the file with the nominal size closest to the
zoom level icon size is picked. After loading the actual pixbuf size is
compared to the the maximum icon size, which is 96 for normal zoom, and
is scaled like normal icons, ending up being twice the nominal size. If it
is larger it gets scaled down to fit the maximum size.
This icon is then scaled to the right nominal size, given the actual
nominal size that was loaded, but if the *real* size of the icon then
would be larger than the requested nominal size the the scaling factor is
tweaked so it would fit in the requested nominal size.
This (if my reading the code is correct) seems to indicate that bitmapped
icons (as shown in the icon container) can never be larger than the
nominal size of the current zoom level, but they can be stored as smaller
than the nominal size, as the code never looks at the actual size except
for the final max-size capping.
I think that the SVG patch I proposed implements exactly this for SVG
icons, although they are currently handled a bit differently. I think this
change is the right thing to do, although it sort of breaks the svg
theming "API" from nautilus 1. I will spend some time later pondering what
this means for top-left text box specifications, and how to do SVG icons
that are portable between nautilus 1 and nautilus 2.
I will commit this change now. If we feel strongly about it later we can
always revert it, but it gives a good performance increase that we want
the users to see.
Darin, If you do a release today, can you please bump the librsvg version
and require the new one in nautilus.
/ Alex
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]