Open Bug 844258 Opened 11 years ago Updated 2 years ago

Misplacement of <use> elements in svg documents.

Categories

(Core :: SVG, defect)

Product:
Core
Component:
SVG
Version:
22 Branch
Platform:
x86_64
Linux
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: aaron, Unassigned)

References

Details

Attachments

(5 files)

Flag_of_the_United_States.svg
1.46 KB, image/svg+xml
Details
screenshot of the malfunction, on the right is a correct rendering, on the left is an incorrect rendering done by firefox.
2.30 MB, image/png
Details
The same issue in Firefox Nightly for Android
26.11 KB, image/png
Details
An overlay of the incorrect firefox rendering atop the correct chromium rendering.
99.44 KB, image/png
Details
Screenshot of Chrome 39 vs Firefox 36.0a1 (Mac OSX 10.9.5) showing incorrect placement of <use> elements in Firefox.
216.44 KB, image/png
Details 
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 Firefox/19.0
Build ID: 20130219185710

Steps to reproduce:

Open an existing document with transformed <use> elements(such as Flag_of_the_United_States.svg).


Actual results:

The <use> elements were displayed with incorrect placement.


Expected results:

The <use> elements should've been placed in the way described by the standard, and implemented in earlier versions of Firefox(at least FF12) as well as other implementations(rsvg, inkscape, webkit)
Looks OK to me. What exactly is wrong with the rendering?
Oh and does toggling hardware acceleration make any difference?
Toggling hardware acceleration doesn't seem to fix the issue for me.
(In reply to Robert Longson from comment #1)
> Looks OK to me. What exactly is wrong with the rendering?

Take a look and compare to another SVG implementation like rsvg(used in eog) or webkit, look specifically at the placement of the stars, it should be fairly obvious.
I did that, I checked against Opera and it looks exactly the same.
I'm checking on Windows though so it's possible it's a platform issue.
Issue is the same on FF19 for Windows and Nightly for android, so I'm not sure...
Can you attach a screenshot?
Seems to happen on everything I use to test it.
I have been encountering this issue in Firefox 33.0.3 and 36.0a1 on OSX 10.9.4 and Windows 7. The screenshot is of this CodePen: http://codepen.io/mcous/pen/FfxkC.

Each of the five rectangles should be bisected by a red line, but when I try it in Firefox, three of the rectangles are shifted to the left. However, as per the original post, I also tested it in FF12 and got the correct result. It also renders correctly in Chrome, Safari, IE, and Opera.
Since this seems to be a regression somewhere between Firefox 12 and Firefox 19 perhaps someone could find a regression range using http://mozilla.github.io/mozregression/
Ran mozregression (downloading nightlies) and got:

Last good revision: 588424024294 (2012-08-02)
First bad revision: 89dcadd42ec4 (2012-08-03)
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=588424024294&tochange=89dcadd42ec4
I bisected the commits and found:

The first bad revision is:
changeset:   101179:b077c43a4306
user:        Jonathan Watt <jwatt@jwatt.org>
date:        Thu Aug 02 00:29:36 2012 +0100
summary:     Bug 776054 - Flip the prefs to enable the use of display lists for SVG painting and hit-testing. r=roc.

http://hg.mozilla.org/mozilla-central/rev/b077c43a4306
Confirmed to still be an issue in current versions.
What is the tradeoff for not using display lists here? Would it be a noticeable perf hit?
I noticed this issue can also be seen on e.g. GitHub with slightly misaligned glyphs on buttons.
Disabling diplay lists with the prefs causes more issues there, since the glyphs are then completely not drawn (potentially some fixes were included in the display lists for SVG that were not applied to the non-display-list path?) -- Should I open a new bug for that?
disabling display list bugs are highly unlikely to be fixed. It's a huge perf hit not to use them in most cases.
Right. Any idea why this misaligning occurs? Is it a rounding issue? It seems the place where this is noticed specifically is in case of (very) large scale factors. The flag uses `scale(650)`.
To summarize bug 1361366, Firefox seems to work in multiples of 1/60 of a pixel (probably using integer arithmetic; see bug 177805).
Now 1/60 of a pixel should be small enough, but some SVGs use weird scaling and work with very small lengths (I saw one that scaled everything down to 1 pixel, probably to use relative sizes; maybe there's a program that generates such SVGs).
So I guess fixing this bug has some performance implications that should be considered as well.  Increasing the precision would mess with bug 552412, for instance.  Using floats instead of ints would be another solution which was discarded due to performance; then again computers have gotten better since then (well, not mine, but the average one) so I don't know if it still applies.
Using floats is probably the best way to deal with it. Especially if you're working with any sort of vector images, designers are going to assume real numbers, and not ints, are used for the "free scale" precept behind vector, so both very large pixel sizes and subpixel sizes are both handled without loss.

In modern CPUs, the ALU is very likely to be extremely efficient with floats, especially if the compiler is leveraging the various SSE extensions; combined with the raw power we have today, I severely doubt that it'll be user-noticeable in any way.
(In reply to Mark Straver from comment #24)
> Using floats is probably the best way to deal with it. Especially if you're
> working with any sort of vector images, designers are going to assume real
> numbers, and not ints, are used for the "free scale" precept behind vector,
> so both very large pixel sizes and subpixel sizes are both handled without
> loss.
> 
> In modern CPUs, the ALU is very likely to be extremely efficient with
> floats, especially if the compiler is leveraging the various SSE extensions;
> combined with the raw power we have today, I severely doubt that it'll be
> user-noticeable in any way.

Another possibility is moving the fixed point in the fraction, though I suppose you'd have to move it a lot to fix this particular case. Maybe it's worth taking a look at how Chromium handles this, since they tend to render SVGs faster than Firefox without the compromise in positional accuracy. ;- )
Also, one wonders how performance critical it is if the chosen denominator is 60 and not, say, 64. When a division is doing a shift's work I have a hard time thinking that too much attention has been paid to it.
The initial suggestion in bug 177805 was using 1/720 px. I haven't read through all of that bug, but maybe it was a better idea to use that magic number instead of 1/60th if people want to stick with ints? Even if people scale down to 1px to have fractional measurements, one would still have decent accuracy (rounding off to 0.14% of the image) -- although it will of course limit the largest size possible proportionally by a factor 12.
As I mentioned, increasing the precision would improve the lower limit but reduce the higher one, so if someone made an image 3,000,000×1,000,000, for example, there'd be overflow problems.  Plus it only improves the behavior for this particular case rather than solving the problem.
If using floats really affected performance maybe a solution would be to implement floating point manually, using a common scale factor for all values in a group, but I don't think it's worth it; probably most platforms handle floats well.  (Not sure about mobile, does Android/ARM deal with floats efficiently?)
I think float performance of ARM on modern processors is good enough to just use floats there. A quick search for some tests there show that all ARM processors use only 1 (sometimes 2) processor cycles for a floating point operation, and > 1 GFlops as a result.[1] You'll probably not notice any significant difference, whatsoever, especially not in real-world situations.

[1] http://www.anandtech.com/show/6971/exploring-the-floating-point-performance-of-modern-arm-processors
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: