Created attachment 14127 [details]
SVG image used in screenshot

I saw that screenshot too. However I tried opening that attachment and
although Sodipodi can open it, I got an error that it wasn't a
supported file type for the desktop background. Weird.

Ben: what version of librsvg do you have? Alex L. couldn't duplicate
Uraeus's problem with latest librsvg, he said, on nautilus-list.

The same thing happens if you try to view the svg in eog.  It appears
it's being converted to a raster graphic in eog and
 when you zoom in, it appears jagged.

That svg looks bad for me too as a stretch background.  Using
librsvg-2.2.3 and gtk+-2.2.1

To help people reproduce. I use the background capplet, choose the
tiger and select the scaled button to make it fullscreen.

Adding Seth to CC as he is the creator/owner of the background
settings capplet.

I'm neither the owner nor the creator ;-) The code was completely
rewritten from what I originally wrote... Not sure who's the owner at
this point.

Anything that sets the background should be scaling using
from_file_at_size.

Would be great to have this fixed for 2.6

this really should be considered a blocker for gnome 2.6. if not, you
get really pixellated backgrounds if your background is a SVG image.

it should be pretty trivial to
s/gdk_pixbuf_new/gdk_pixbuf_new_at_size/g in the capplet and the
actual bit that sets the background(nautilus? gnome-settings-daemon?)

cc'ing dobey, as he owns the new capplet. raising priority.

cc'ing myself

This is unpleasant but not a blocker.

Also, Uraeus: fwiw, GNOMEVER2.6 is for bugs in 2.6. 2.6 is not
released yet, so please don't use the keyword ;-)

I've tried it and it doesn't seem to help.  I'm definitely doing
at_size 1280 x 1024, but I'm still getting a scaled image.  I believe
the problem is the following:

(gnome-settings-daemon:1285): GdkPixbuf-CRITICAL **: file
gdk-pixbuf-io.c: line 811 (size_prepared_cb): assertion `width > 0 &&
height > 0' failed
 
(gnome-settings-daemon:1285): librsvg-WARNING **: rsvg_start_svg:
width and height not specified in the SVG, nor supplied by the size
callback

Not sure what to do about this, though it does explain why it's still
pixelated.  This is running librsvg 2.5.0 and gtk+ 2.3.4.

Also, is there any way to tell gdk pixbuf that you want it to use the
exact dimensions you give, instead of keeping the aspect ratio?  It
seems like this would be preferable when setting the background to
fill the screen.  Sorta silly, for example, to draw the tiger at
1024x1024 and then do pixelated scaling to 1280x1024.

i guess a good test would be to see why this gdk-pixbuf warning happend:

gdk-pixbuf-io.c: line 811 (line 806 in my CVS)

its value is passed directly into RSVG, which explains the next
warning. if you can, chris, set a breakpoint/printf around there and
see what happens.

it looks like gdk-pixbuf always tries to keep the aspect ratio the
same (size_prepared_cb), unfortunately. i'd say that was a bug and
should be fixed ASAP (fwiw, this was not in my original patch)... you
didn't ask for a 1024x1024 image, you asked for 1280x1024, regardless
if the specs now say:

"830  * The image will be scaled to fit in the requested size,
preserving its aspect ratio."

If you do change this (which makes total sense to me) the background
applier code is also going to need to be able to request the size of
the image before loading it, so that it can scale keeping aspect
ratio.  This would have to happen before loading the image, of course,
so we don't have to load the image twice.

Also, this would reintroduce the problem that your change would fix
since rsvg doesn't seem to report a size for that particular svg.

rsvg can't report a size if the SVG doesn't have one. technically,
it's legal to omit the width && height <svg> parameters, which means
that the SVG is drawn at its "natural size". unfortunately, that means
that you can't know how big it is without rendering the SVG first.
chicken. egg.

as such, i'd file a bug against any particular SVG that omits a width
and height argument. as you can see, I've never been a fan of that
part of the SVG spec. add a width && height param to your SVGs, damnit.

i'm not in a position to change the aspect ratio bug in GTK+. you'll
have to talk with owen and matthias. it would break API, which may be
frowned upon. then again, maybe you could convince them to add yet
another API for from_file_at_size_i_really_mean_it_damnit()

the "size_prepared" callback does pass in the width && height of the
image. at least it does so when one exists...

if you fix the gtk+ bug, you'll handle the 99% case which is certainly
a big step in the right direction.

I'm pretty sure that if you use an image with a width and height in
the svg, this won't be a bug.  I don't have one to test with though. 
Could you attach one?

inside of librsvg, you'll find:

tests/Artwork.svg (.75 aspect ratio)
tests/Picasso.svg (1.48 aspect ratio)

these are both good tests. "Artwork" is probably better suited to a
desktop background, as it more closely follows the aspect ratio of
most monitors (unless you rotate picasso.svg 90deg, in which case it
has a 1.333 aspect ratio). you should see a picture of San Francisco
and a Picasso drawing, respectively.

Created attachment 25253 [details]
simple gnome-logo background SVG, overlay for dark background colors

see also bug #136395

clahey - it reports 500x500 now for bogus SVGs

clahey - i just tried this and things "just worked" for me.

rsvg --x-zoom=.5 --y-zoom=.5 tiger.svg out.png

gave me a 250x250 image (with most of the tiger cropped)

Attaching a fix for this problem, but with svgs, there are still some
issues.  I'll include them in the following.

I think perhaps the default should be changed to 512.  No reason not to.

I changed the code in settings daemon to allow for unset sizes, just
in case (it assumes a 500 pixel square also.)  However, the pixbuf
loader for svg doesn't seem to be scaling the image from 500x500 up to
whatever size the screen specifies.  Instead it just draws it on a
larger background.

It would be optimal, I believe, to scale the image as if the
width/height were given as 500 in the file.

Also, even if the size is given, text doesn't change aspect ratio if
the aspect ratio of the output changes.  This means, for example, that
if you have a wide svg with text across it and are set it to fill the
screen, the text goes off the screen.  Not sure if the text scales
with the height or with the greater of the two dimensions.

As soon as this patch is committed, I'll file these all as separate bugs.

Sure, but shouldn't the tiger be scaled down by 50% so that it mostly
fits?  (A little would get cut off, but most of it should be there.)

Created attachment 25531 [details] [review]
Scales SVGs as vector when drawing to screen.

chris - librsvg's text support is broken, and i'm not taking bugs
against it until Sven and I get to do some work on it. just fyi.

i can make the "assumed size" 512x512 if none is specified. that'll be
about 10 seconds worht of work. in the case where a width and height
aren't specified, i can make it so that the picture scales up/down
correctly. that'll be a bit more work.

again, however, i think that you need to get a new test SVG. my
patience for working around broken parts of the SPEC and broken SVG
producers is wearing thin.

the important part is that you get this checked into egg and into
Gnome. the rest is just tedium in librsvg that i can work around in my
spare time.

I've been using a number of SVGs from your test directory.  Actually,
some of the ones there have no width and height.

I really don't care too much about fixing files without width or
height.  Very minor as far as bugs go.

we're now assuming a 512x512 canvas and can scale those annoying
unsized SVGs.

The sizing patch looks good and should go in as soon as 2.6.0 ships.
I'd rather see a slightly different approach to the application timer.
Rather than ignoring subsequent changes and just using the existing timers it
should clear existing timers and create a new one.  Otherwise if a user pages
through things quickly

eg
    autorepeat downarrow

we could end up with no delay again

Created attachment 25576 [details] [review]
New patch.  More fixes.

This new patch fixes that last request as well as fixing bug #136715.
 I'd love it if these were separate patches, but they interfere majorly.

Nice.  Please commit as soon as 2.6.0 ships

Adding BLOCKED_BY_FREEZE keyword.

Applied.
Thanks