Open Bug 1038309 Opened 6 years ago Updated 4 years ago

SVG Images turns out fuzzy when gets rotated inside of other SVG


(Core :: ImageLib, defect)

28 Branch
Not set



Tracking Status
firefox30 --- affected
firefox31 --- affected
firefox32 --- affected
firefox33 --- affected
firefox-esr24 --- unaffected


(Reporter: dacosta, Unassigned, NeedInfo)



(Keywords: regression)


(1 file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.77.4 (KHTML, like Gecko) Version/7.0.5 Safari/537.77.4

Steps to reproduce:

Rotate an SVG Image inside of other SVG, see for test case.

<svg ...>
            <image xlink:ref="file.svg" transform="rotate(-24)" ...>

Actual results:

The image is fuzzy or pixelated when gets rotated.

Expected results:

image should render correctly.
Attachment #8455499 - Attachment mime type: text/plain → text/html
Component: Untriaged → ImageLib
Product: Firefox → Core
Regression window(m-c)
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 ID:20131118182715
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 ID:20131118183211

Regression window(m-i)
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 ID:20131117233137
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 ID:20131118003137

Regressed by: Bug 923341
Blocks: 923341
Ever confirmed: true
OS: Mac OS X → All
Keywords: regression
I believe this regressed with, and was already broken on non-windows platforms.

When there's no rotations involved, then we compute the final on-screen size of the svg and pass that into SVG drawing, but with rotations we give up [1] and tell the svg to draw at it's inner size (50x50 in this case).

Without caching of SVG's this doesn't matter, but with caching we'll rasterize the image at 50x50 (and insert it into the cache) and then scale it up when drawing to the screen.

I expect we want to still extract the 'scale factors' when a more complicated transform is present so we can avoid these scaling artifacts.

Want to work on this Seth?

Flags: needinfo?(seth)
Depends on: DrawAPIRefactor
Flags: needinfo?(seth)
So I expected this to be fixed by bug 1037713, but it's still busted. I'm going to needinfo myself to investigate this further. The infrastructure should be there to support this, but somehow we're not taking this transformation into account.
Flags: needinfo?(seth)
Duplicate of this bug: 1112558
any news or a work around until fixed? Thx a lot!
any news or update?, Thanks a lot!!
I'd wait another day and try the nightly build, once the fix for bug 1128467 is in.
The reporter's testcase (images of Homer Simpson) look identical to me in Google Chrome and Firefox Nightly 49.0a1 (2016-05-21) on my Windows 10 desktop machine.
Yes, it looks identical for me too. But please, take a look at the bug which I hope renders differently.
You need to log in before you can comment on or make changes to this bug.