Re: [Nautilus-list] changes to svg icon handling

[Alex Larsson <alexl redhat com>]

On 27 Feb 2002, Michael Meeks wrote:

> Hi Alex,
> 
> On Mon, 2002-02-25 at 21:18, Alex Larsson wrote:
> > The nominal size is the target size of the icon, and it's max size. bitmap 
> > icons may be smaller than their nominal size though, and they won't 
> > forcedly scaled up to the nominal size.
> 
> 	I don't believe that's the case, I think icons are typically larger
> than their nominal size as they come off disk, and as long as they are
> smaller than the maximum size they are not scaled, if they are scaled
> they are scaled to the maximum size ~= 2x the nominal size. It is
> certain that pixmaps that are loaded at the nominal size are not scaled
> to the maximum size when they are loaded.

Yes. I've got a better idea of how this works now.
 
> > [Note: The max width for the first level of max icon size is 
> > MAXIMUM_ICON_SIZE * requested_size / NAUTILUS_ZOOM_LEVEL_STANDARD. Which 
> > gives you an exact factor of 2, but the icons are then later scaled down 
> > to be no larger than the icon nominal size. Unless i misread the code. ]
> 
> 	I think you mis-read it :-)

Yeah. I read this how it was meant to be, missing the subtle bug. I fixed 
the bug in cvs now, but my mail about it has not reached nautilus-list 
yet. Conclusion was: fixing typo -> save 4 megs of memory.

> > The emblem seems to be rendered at 75% of the size of the corresponding 
> > icons. How is that highly sub-optimal?
> 
> 	Well - it's the wrong size for the emblems; this calculation needs
> re-adjusting, it doesn't mach the way the pixmaps are handled there is
> acute badness here cf:
> 
> 	http://primates.ximian.com/~michael/bad1.png
> &	http://primates.ximian.com/~michael/bad2.png

Yeah. This looks bad, although it is due to several causes.
 
> > I agree it's sort of a 
> > non-obvious place to do this calculation, but it makes sense to have 
> > emblem size depend on the icon size, does it not? 
> 
> 	Quite possibly, but not to have the emblem so huge ;-) if we use this
> factor it needs to be dramatically reduced - but then it's prolly worth
> fixing the other emblem rendering bugs first since they may be related
> to this issue.

The core problem here is the way emblem handling is set up. For bitmap 
emblems, when the zoom level is such that e.g. the nominal icon size is 72 
pixels it looks for emblem-nowrite-72.png. But for emblems, this icon is 
not normally 72 pixels, it is just a size that matches icons that are 72 
pixels. But the current svg code would always render it at 72 * 0.75 
pixels, which can be a bit large. And then at the end they are scaled down 
to 48x48 which is the max size all emblems.

> > I will look at the top-left text issue tonight.
> 
> 	It seems text is still somewhat badly broken, and the svg icons are
> still unnaturally small, compared with the pixbuf icons, eg. switch
> between UnscaleableGorilla  and Scaleable~ and you'll see the
> discrepancy ~ 1/3rd larger or so.
> 
> 	IMHO a good soln' to this might be to bump up the nominal size to
> nearer the maximum size - or conversely to bump down the maximum size to
> nearer the nominal size [ and set the default zoom level higher, and
> extend the zoom range to > 400% ].
> 
> 	What do you think ?

We can't change the nominal sizes, that would break all bitmapped icon 
handling. But I have a plan now for how to initially render the svg at the 
right size, taking into account both the size specified in the svg, the 
zoom factor, and the maximum sizes. This will need some more changes in 
librsvg, but I think it will finally fix this issue.

/ Alex