Bug 152834 – SVG Rectangle strokes thicker than specified, in Safari and Webkit nightly (does not impact simple lines)

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: SVG

[Andre-John Mas]

Created attachment 268460 [details]
test-case

When a 'rect' (rectangle) is drawn in SVG I observe the stroke being thicker than specified 'stroke-width' and the equivalent specified value for a 'line'.

This is only an issue in SVG and specifying shape-rendering="crispEdges" does not help.

I have not found any work around and this impacts quality of rendered images.

I have not tested for other stroke scenarios.

SVG Sample
----------

  <!-- Line thickness as expected -->
  <svg id="svg1" style="width: 200px; height: 200px; background: white" shape-rendering="crispEdges">
      <line x1="0" x2="200" y1="20" y2="20" stroke="#000000" style="stroke-width: 1px;"></line>
      <line x1="0" x2="200" y1="40" y2="40" stroke="#000000" style="stroke-width: 2px;"></line>
  </svg>

  <!-- Line thickness does not correspond to simple lines -->
  <svg id="svg2" style="width: 200px; height: 200px; background: white" shape-rendering="crispEdges">
      <rect x="80" y="80" width="40" height="40" stroke="#000000" fill="none" style="stroke-width: 1px;"></rect>
      <rect x="70" y="70" width="60" height="60" stroke="#000000" fill="none" style="stroke-width: 2px;"></rect>
  </svg>

Browsers Tested In
------------------

I observe this behaviour:
  - Webkit nightly 2016-07-01 (MacOS X 10.11)
  - Safari 9.0.2 (MacOS X 10.11)
  - Safari and other webkit based browsers on iOS 9.2

Behaves as expected:
  - Opera 34 (MacOS X 10.11)
  - Google Chrome 43 (MacOS X 10.11)

[Andre-John Mas]

Created attachment 268645 [details]
Screenshot showing what I am seeing

[Andre-John Mas]

Created attachment 268647 [details]
second test case

[Andre-John Mas]

I looked at Chromium build 100008 (https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Mac/100008/), from September 2011, and the issue does not present itself there. I was looking to establish at what point the behaviour diverged in Google Chrome and Safari, but this offered no clue.

[Said Abou-Hallawa]

Created attachment 268690 [details]
third test case

[Said Abou-Hallawa]

I can't reproduce this bug in the shipped Safari on Mac OS X El Capitan. The display is identical with Chrome and FireFox on the same machine. I tried the webkit nightly build  and the display is as expected also.

[Andre-John Mas]

I certainly see the issue with a 13" MacBook Air (MacBookAir6,2), without extra display and with the iPad Air 1.

I have since tested with other computers:
 - 15" MacBook Pro , late 2008 (MacBookPro5,1), MacOS 10.9.3: looks fine
 - 27" iMac, mid 2011 (iMac 12,2), MacOS 10.11.2: thick line issue
 - Mac mini, early 2009 (Macmini3,1): thick line issue

For the MacOS test, what machine are you using?

Are there any screen metrics available via the DOM, that I could look at to see if there are differences in the indicated screen DPI or something similar? I want to avoid delving into the code if I don't need to, for initial analysis.

Note, I wasn't able to test Webkit nightly with MacOS X 10.9, so I can't tell whether the issue is due to regression or something else.

[Andre-John Mas]

Just noticed something on my 13" MacBook Air, when I tested your test case (Safari & Webkit nightly):

a: Looks ok:
  - New tab
  - Paste in and display test case

b: Looks problematic:
  - New tab
  - Open test case page
  - Display web inspector


c: Looks problematic:
  - New tab
  - Visit any website, www.webkit.org
  - Display web inspector
  - Open test case page

Note in cases b & c closing the inspector and reloading the page in the same pane doesn't correct the line thickness.

Further, depending on whether I open your test case from the URL or file, the behaviour is different. From the web site it looks fine (as describe in cases b & c), but is always problematic from file.

[Said Abou-Hallawa]

Yes, you are right. It seems to be hardware specific. I can't repro this bug on MacBookPro11,3. But I can repro it on MacPro6.1 only on WK2.

[Said Abou-Hallawa]

Created attachment 268699 [details]
Screenshot-MacBookPro11,3

[Said Abou-Hallawa]

Created attachment 268700 [details]
Screenshot-MacPro6,1

[Brent Fulgham]

Safari, Chrome, and Firefox all agree on rendering for this test case. I don't believe there is any remaining compatibility issue.