Closed Bug 1003763 Opened 7 years ago Closed 1 year ago

CSS centered inline SVG is being rendered blurry


(Core :: SVG, defect)

29 Branch
Not set





(Reporter: johannes.krtek, Unassigned)




(3 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release)
Build ID: 20140421221237

Steps to reproduce:

Add any inline SVG element (including a visible shape) to the HTML body element. Center the SVG with CSS. Resize the browser window to an odd pixel width.

Actual results:

CSS centered inline SVG elements are being rendered blurry at odd window widths.
(in the attached screenshot the right edge of the black rectangle is blurred)

Expected results:

Rendering should be consistent independent of the positioning of the graphic. That is the inline SVG should be rendered like external SVG (linked via image source or CSS background-image).
Thank you for your quick response!

I'm aware of the shape-rendering property – but it does not solve the problem of, let's say, small icons.

With 'crispEdges' set, the icon is not recognizable any more. If you comment out the 'shape-rendering' property you will see antialiased vertical edges or crisp edges – depending on the window width. With 'text-align: center' too commented out, the icon's vertical edges will always be crisp as I think they should be because the icon itself has only integer pixel values (and this is consistent with the rendering of the same SVG as img or background-image).
I read the cairo FAQ but it misses the point. My issue is not about creating a proper icon – the icon I am using is perfectly alright for the demonstration's purpose, it is not based on integer coordinates in combination with strokes/lines. 

Please have a look at the following comparison chart and it's compilation of screenshots:

It is remarkable, that inline SVG in Firefox is being rendered quite differently in comparision with SVG images, background images and inline SVG in other major browsers, which I consider to be a bug.
I set the status back to unconfirmed just in case my last unanswered posts have not been reviewed.
Resolution: INVALID → ---
Component: Untriaged → SVG
Product: Firefox → Core also points out that there's the issue of disagreeing with other browsers, which matters.  Why do we differ?
(Is the cross-browser difference that we're doing sub-pixel positioning of the SVG and other browsers aren't?  Should we be doing so for SVG-via-img?  And should we be for inline SVG?)
Kaelig already opened another bug report (bug 1046835) which seems to cover the same topic.

Maybe the bug reports could be merged?

And yes, most likeley the inline SVGs get blurry because of sub-pixel positioning (that is why the bug can be repoduced easily by changing the viewport size in combination with centered SVGs). I would propose to never use sub-pixel positioning for any kind of SVG.
Duplicate of this bug: 1107041
I ran into the same bug with sub-pixel paddings. Here is my test case: <>.

Sub-pixel paddings occurred in my case, when they were set to .2em, so nothing exotic going on here, just all SVG icons becoming blurry. Note that the SVG data only becomes blurry in 3 of 5 embedding cases: direct embed, <object> and <iframe>. <img> and CSS backgrounds are not affected by this bug.
Attached image blurry-svg.png
how can someone (say… GitHub) place a pixel-perfect SVG icon inline, but make sure it is aligned to the pixel grid?

the other test case shows that an <img> or <background>, does the trick, but there needs to be a way using a directly embedded <svg> element.

shape-rendering: crispEdges will not align the svg correctly, but mangle it, so it’s not the solution.
oh, and bug 1046835 is *not* a duplicate of this one.

the bug we’re talking about is about the subpixel alignment of *inline* SVGs due to surroundingtext not being aligned to the pixel grid.

the other one is a antialiasing bug on OSX AFAIK.
Duplicate of this bug: 1522927

Any movements for 5 years?

Closed: 7 years ago1 year ago
Resolution: --- → DUPLICATE
Duplicate of bug: 608812
You need to log in before you can comment on or make changes to this bug.