Closed Bug 539436 Opened 14 years ago Closed 9 years ago

SVG path disappears when length exceeds 32768

Categories

(Core :: SVG, defect)

x86
Windows Vista
defect
Not set
minor

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: prekgeo, Unassigned)

Details

Attachments

(4 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)

When you draw an SVG path with length 32767 everything is fine. If you go to a length of 32768 the path disappears. This does not seem to apply for vertical or horizontal paths. There has to be a slight degree.

Reproducible: Always

Steps to Reproduce:
1. Open test case HTML file.
2. The blue box has 1 path with length 32767 and is OK.
3. The red box has 1 path with length 32768 and fails.

Actual Results:  
Red box is empty.

Expected Results:  
Both boxes should look the same.
Attached file test case
Jeff, can I interest you in looking at this? It seems like cairo isn't drawing the line but I can't figure out why.

Changing the 2nd path in DOM Inspector from d="M100,100L110,-32668" to d="M100,100L109,-32668" produces a thin vertical line that gets fatter as the first L argument gets closer to 100.
Status: UNCONFIRMED → NEW
Ever confirmed: true
So this doesn't show up OS X, which isn't a huge surprise. It does happen on win32 presumably because of a fixed point precision issue. I'll take a look when I get a chance.
Comment on attachment 427297 [details]
test case showing incorrect rendering of a path with large coordinates

The two paths in this test case should ideally have two line segments each. But due to this bug, the second path has only one line segment. I have seen this behaviour in both Windows XP (Firefox 3.5.8) and Linux (Firefox 3.5.6 on Fedora 11)
Status update:
1. Able to reproduce using the stable version [1];
2. Unable to reproduce using a nightly build [2].
Both tests performed on Windows (Vista SP2).

[1] Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8 ( .NET4.0E)
[2] Mozilla/5.0 (Windows; Windows NT 6.0; rv:2.0b3pre) Gecko/20100728 Minefield/4.0b3pre ( .NET CLR 3.5.30729)
Based on comment 2, I'd guess that this probably became fixed on trunk due to a cairo upgrade.

It'd be nice to have a reduced fix-range (between trunk nightly builds) to confirm that, if anyone's up to tracking that down.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: