[Nautilus-list] Re: SVG icons



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]