Bug 31862 – Lines in svg shift up 1 pixel

• Component: SVG
• Status: RESOLVED INVALID

Created attachment 43831 [details]
A minimal test case for this bug.

Steps to reproduce:

1. Open the attached xml file, which draws a line at y=0.
2. Observe that the line does not appear.
3. Change the zoom level (cmd +/-) and observe that the line appears.

Expected results: The line should always be visible.

Actual results: The line is only visible in some zoom levels.

Discussion: It seems that this problem is specific to core-graphics (rendering on mac), and does not reproduce on chrome windows or linux which use skia for rendering. I encountered this problem when I was trying to draw a line between 2 rectangles, the line appears 1 pixel higher in Safari mac than it does in other browsers. It seems the all the horizontal lines in the SVG appear 1 pixel higher. It seems that adding 0.5 to the y position causes the line to be displayed correctly.

Other browsers tested:
- webkit nightly/Safari 4.0.3 Mac - fail.
- Chrome Windows/Linux - OK.
- Chrome Mac - fail.
- Firefox 3.5 on Windows - OK.
- Firefox 3.0 - fail.

[Eric Seidel (no email)]

http://www.w3.org/TR/SVG/render.html#PaintingShapesAndText

"A stroke operation is centered on the outline of the object; thus, in effect, half of the paint falls on the interior of the shape and half of the paint falls outside of the shape."

So a stroke of 1px will end up with only 0.5px of visible stroke at normal zoom.  0.5px might fall below the minimum displayed stroke and might end up hidden.  I'm not yet certain.


From the Cocoa Drawing Guide (which talks about the NS* wrappers around CoreGraphics):
https://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CocoaDrawingGuide/Paths/Paths.html#//apple_ref/doc/uid/TP40003290-CH206-BBCHFJJG

Fractional line widths are rendered as close as possible to the specified width, subject to the limitations of the destination device, the position of the line, and the current anti-aliasing setting. For example, suppose you want to draw a line whose width is 0.2 points. Multiplying this width by 1/72 points per inch yields a line that is 0.0027778 inches wide. On a 90 dpi screen, the smallest possible line would be 1 pixel wide or 0.0111 inches. To ensure your line is not hidden on the screen, Cocoa nominally draws it at the screen’s larger minimum width (0.0111 inches). In reality, if the line straddles a pixel boundary or anti-aliasing is enabled, the line might affect additional pixels on either side of the path. If the output device were a 600 dpi printer instead, Quartz would be able to render the line closer to its true width of 0.0027778 inches.

So I'm not sure.  I'm not sure yet if CG's behavior is correct according to SVG or not.

[Eric Seidel (no email)]

I think that the "problem" is that CG will not render horrizontal lines below a specific thickness.  I'm not sure CG's behavior is actually incorrect here.  Antialiasing could be related.  I'm not sure if WebKit's SVG implementation supports 'crisp-edges' (which would turn of Antialiasing) or not yet.

[Dirk Schulze]

We do not support crisp-edges yet but this is related to AA. The same behavior can be seen in all browsers on macOS.