594695 - svg files in image tags aren't scaled correctly by the layout.css.devPixelsPerPx pref

Status: RESOLVED WORKSFORME

(Core :: SVG, defect)

Description

[Daniel Brooks [:db48x]]

Setting layout.css.devPixelsPerPx to 2 will double the size of everything, but in a build with the changes from bug 276431, images with svg content are instead scaled down to half their original size. See the testcase from that bug, which I've put into this bug's url field.

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6pre) Gecko/20100909 Firefox/4.0b6pre

Comment 1

[Daniel Brooks [:db48x]]

Oh, and may I suggest adding a reftest that compares a normal image and an svg image?

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: SVG for testcase

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: testcase

(In reply to comment #0)
> Setting layout.css.devPixelsPerPx to 2 will double the size of everything, but
> in a build with the changes from bug 276431, images with svg content are
> instead scaled down to half their original size.

This is indeed broken, but in general, it's not quite as simple as just scaling down instead of up.

In a testcase with a fixed width/height on the image (rather than 100% height/width as in the testcase you linked to), the SVG content always paints at the same fixed size, when you increase the layout.css.devPixelsPerPx property.

The size of the <img> element inreases, but the SVG content paints at the original "normal" zoom factor.

Comment 4

[Daniel Holbert [:dholbert]]

Requesting blocking2.0.  IMHO, this needs to be addressed for betaN, but not beta6.

Comment 5

[Daniel Holbert [:dholbert]]

Removing "regression" keyword, since this isn't a true regression. We didn't used to support svg-in-img-tag at all, and now we do, albeit with this quirk.

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to comment #1)
> Oh, and may I suggest adding a reftest that compares a normal image and an svg
> image?

Sure, I can do that with this bug's patch. (We already have at least one reftest that compares SVG vs PNG for a CSS background -- background-image-rect-1svg.html vs background-image-rect-1png.html -- but it'd probably be good to have one for <img> too)

Comment 7

[Daniel Holbert [:dholbert]]

Attachment: Patch 1: Use nsLayoutUtils::DrawSingleImage

This patch makes nsSVGImageFrame::PaintSVG use nsLayoutUtils::DrawSingleImage, instead of imgIContainer::GetFrame.  I haven't tested it thoroughly, but it works on simple testcases with both PNG and SVG images.  I'm running it through TryServer to see if it breaks anything.

Comment 8

[Daniel Holbert [:dholbert]]

Comment on attachment 473829 [details] [diff] [review]
Patch 1: Use nsLayoutUtils::DrawSingleImage

d'oh, that last comment & patch was for bug 272288. Sorry for the spam. :)

Comment 9

[Greg Edwards]

Attachment: The issue seen on www.apple.com

This is very obviously breaking www.apple.com which is using an SVG background for their navigation.

Comment 10

[Daniel Holbert [:dholbert]]

You're right -- but it's not this bug, it's bug 600207.
(FWIW, the SVG image in question on that header-bar is https://www.apple.com/global/nav/images/globalnav_text.svg )

(This bug here is about the effects of manually setting a specific about:config pref. So unless you've manually tweaked that pref, this isn't the bug you're looking for.)

Comment 11

[Daniel Holbert [:dholbert]]

Comment on attachment 661292 [details]
The issue seen on www.apple.com

Actually, it looks like that is this bug after all (at least, I only get the menubar-broken-into-2-rows thing from your screenshot if I set  layout.css.devPixelsPerPx to 2 and trigger this bug)

Sorry for misunderstanding -- so just to be clear, is that pref toggled to "2" in your profile?

(I don't quite understand why the UI in your screenshot isn't affected by the pref-tweak -- my UI turns huge when I tweak the pref.)

Comment 12

[Greg Edwards]

Yes, I have manually set devPixelsPerPx to 2.0. Firefox is riddled with a multitude of different DPI related bugs otherwise.

Comment 13

[Greg Edwards]

Almost forgot, you could say the UI is "huge" in my screenshot, since the desktop resolution is 2880x1800 and Windows is set to 192DPI. (I am using the one laptop on the market which uses this resolution. ^^)
PS. It seems both bugs are afflicting the Apple header at once?

Comment 14

[Greg Edwards]

This appears to be fixed. I can't replicate on the Apple header any longer, though the header still suffers from Bug 600207.

Comment 15

[Daniel Holbert [:dholbert]]

Whoah, you're right! WORKSFORME too (using attached testcase & apple.com)

Comment 16

[Daniel Holbert [:dholbert]]

Fix range:
==========
Last bad nightly: 2012-10-31
First good nightly: 2012-11-01

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=bed18790882f&tochange=5bd5bb168eb1

I suspect it was fixed by this cset:
885fb1477a95	Robert O'Callahan — Bug 804062. Move device-pixels-per-CSS-pixel preference logic into nsIWidget::GetDefaultScale. r=jfkthame The only behavior change caused by this patch should be that nsDeviceContexts with no widget (mainly printing, I think), default to a devpixel-per-CSS-pixel ratio of 1.0, ignoring any prefs set.