[Nautilus-list] Re: SVG Gorilla performance in nautilus ...

[Alex Larsson <alexl redhat com>]

On 23 Feb 2002, Michael Meeks wrote:

> 	Primarily the problem is that the SVG view of the world has a somewhat
> arbitrary width/height that we equate with pixels in librsvg.
> 
> 	The code in libnautilus-private/nautilus-icon-factory.c has some
> interesting features such as:
> 
> static CacheIcon *
> scale_icon (CacheIcon *icon,
> 	    double scale_x,
> 	    double scale_y)
> 
> 	auto-icon scaling for icons & emblems that are too large to start with,
> thus it seems most svg elements are initially rendered far too large,
> and then interpolated down at some considerable computational expense -
> not least that we have to render far more gradient pixels that we might
> otherwise need to.

Not only is this expensive. It also means that the SVG icons are not 
rendered at the "correct" size. Where correct means 100% should give icons 
of size NAUTILUS_ICON_SIZE_STANDARD, e.g. 48x48. This does not happen, 
instead the size depends on the size embedded in the svg file. You can see 
this clearly when switching between gorilla and a non-svg theme.
 
> 	This of course is substantially hidden by the auto-scaling. For
> example, while many emblems are around the right size needing minimal
> scaling, some are pretty out of line:
> 
> Opened (570,570) at zoom
> '/home/michael/.nautilus/themes/ScalableGorilla/emblem-nowrite.svg':
> 0x85bc3f0
> Scaling icon to '47,47
> 
> 	So we render the nowrite emblem at 570 pixels square and then
> interpolate it down to 47x47 :-)

Yeah :(

> 	Worse than the emblem issue is the more commonly rendered svg icons
> themselves, for which I've lost the data, but it seems we render them
> somewhat too large by a factor of ~4 - and worse, in scaling them we get
> some nasty artifacts and chew RAM.
> 
> 	So - clearly the solution is to scale them to the correct size as we
> render them from svg[1], and win on rendering and scaling, so I added
> this to librsvg:
> 

I looked at this a bit too, after your first mail, but I did the rsvg part 
a bit different. I added a new function:
GdkPixbuf  *
rsvg_pixbuf_from_file_at_max_size (const gchar     *file_name,
				   gint             max_size,
				   GError         **error)

Which loads a svg and makes the max of width/height be max_size, and 
scales keeping aspect ratio. I think this is more what you want here.

> 	To get the scaling right first time - so, this results in a fairly
> substantial improvement, making really large svg icon rendering
> relatively snappy - but there are several issues:
> 
> 	* Not enough information is propagated to where we render the
> 	  svg, indeed we only have a 'size_in_pixels' parameter pushed
> 	  down the last several layers. It is really not clear what this
> 	  number is good for, with a factor of 2 multiplier it provides
> 	  something approximating what you might expect in layout terms,
> 	  otherwise you get a really odd layout effect in the icon view.

Passing actual_size_in_pixels as the max_size argument seems to give me 
icons that have the same size as the bitmapped ones. This seems like the 
correct behaviour to me, although it makes gorilla have smaller icons 
than when it currently has.

> 	* This doesn't fix the emblem rendering / scaling issues, which
> 	  perhaps are victims of the same size_in_pixels uncertainty I
> 	  suffer, but could do with the same sort of loving.

My nautilus patch is just:
diff -u -p -r1.255 nautilus-icon-factory.c
--- nautilus-icon-factory.c     2002/02/21 19:26:46     1.255
+++ nautilus-icon-factory.c     2002/02/24 00:01:14
@@ -1383,7 +1383,7 @@ get_next_icon_size_to_try (guint target_
 static GdkPixbuf *
 load_pixbuf_svg (const char *path, guint size_in_pixels, gboolean 
is_emblem)
 {
-       double actual_size_in_pixels, zoom;
+       double actual_size_in_pixels;
 
        /* FIXME: the nominal size of .svg emblems is too large, so we scale it
         * down here if the file is an emblem. This code should be removed
@@ -1394,9 +1394,8 @@ load_pixbuf_svg (const char *path, guint
        } else {
                actual_size_in_pixels = size_in_pixels;
        }
-       zoom = actual_size_in_pixels / NAUTILUS_ICON_SIZE_STANDARD;
-
-       return rsvg_pixbuf_from_file_at_zoom (path, zoom, zoom, NULL);
+
+       return rsvg_pixbuf_from_file_at_max_size (path, actual_size_in_pixels, NULL);
 }
 
 static gboolean

Which seems to fix the emblem problem too.

> 	* The in-icon text display information is synched to the old
> 	  version of what the rendered size should be, and worse, since
> 	  we effectively scale the icon for free here we need to be able
> 	  to scale the available text area as well, cf. the code in 
> 	  scale_icon that does that.

Hmmm. I don't seem to see in-icon text at all. Does it work for you?
 
> 	So - the first 2 issues are fairly soluble I imagine, the 3rd issue is
> a more painful. I imagine the best way to solve it to avoid scaling
> issues would be to express the text region not in pixels but in some
> normalized proportion of icon size.
> 
> 	It would seem that we could keep compatibility with old text
> information:
> 
>   <icon size="48" embedded_text_rectangle="38,0,130,110"/>
> 
> 	by doing compatibility maths on load, and adding some tag there to flag
> new data as being proportional - or have a single new tag for all icon
> sizes that is proportional.

Having a proportional specification of the embedded text rect seems like a 
good idea. 

/ Alex