bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

Horizontal lines in SVG circles test

RESOLVED WORKSFORME

Status

()

Core
SVG
RESOLVED WORKSFORME
17 years ago
12 years ago

People

(Reporter: Andrew Simmonds, Unassigned)

Tracking

Trunk
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(4 attachments)

(Reporter)

Description

17 years ago
The first SVG test on http://skeeter-s.com/svg/new-svg.xml shows unwanted 1px
horizontal lines.

- These lines don't appear to be affecting the 100% blue !(aub)n(c) section at all.

- If I move a window over the lines they will disappear leaving me with a clean
image.

- I'm using GCC-3.0.2 maybe this has some weird affect on rounding.

An image will be attached to show what i'm experiencing.
(Reporter)

Comment 1

17 years ago
Created attachment 61432 [details]
circles with random lines through them
WFM. What bit depth are you using?

I'm using 2.96, though. Can you try compiling libart with -fno-strict-aliasing?
(/me guesses)

Comment 3

17 years ago
Ok so this seems to be occuring mainly at 72dpi, where we have 0.05 pixel/twips.
This means that in the conversion from dirty-rect in twips to the dirty-rect in
pixels, we often get values like 100.5, which to me seems very prone to roundoff
errors. Should it be 101 or 100?
Inflating the dirty rect passed to
nsSVGRenderingContext::nsSVGRenderingContext() fixes the problem. Patch to follow.
 

Comment 4

17 years ago
Created attachment 61575 [details] [diff] [review]
proposed patch
Where did 10 and 20 come from?
Comment on attachment 61575 [details] [diff] [review]
proposed patch

You can't hard code this to 72dpi..

You can remove the <1 testing for mDiretyRect below, while you're at it.
Attachment #61575 - Flags: needs-work+

Comment 7

17 years ago
Where did I get the 10 & 20 from?
I just pulled them out of my sleeve! 10 being about equal to half a pixel (at 
72dpi) is just a hand-waving argument. They are magic numbers, but they work. 
No harm in increasing the size of the dirty rect :-)
Initially, I thought that inflating by 1 twip should do the trick to pull us 
into the right direction when converting to pixels, but it sometimes didn't. So 
I tried to be pragmatic and considered that, on the other extreme, inflating by 
a full pixel should not be necessary, and picked some number: 
1 < magic number < a_typical_pixel_size. 
magic_number=a_typical_pixel_size/2 looked good. I don't know why we need this, 
but it works.

What value do you suggest we use? twipsPerPx/2? I deliberatly didn't do that. 
I have no evidence that we actually need to inflate by 1/2pixel. Until I fully 
understand what's going on here, twipsPerPx/2 would be a magical number just 
like 10 & 20, only one that chews up more cycles :-)
10 & 20 seem to fix our problem so why not be pragmatic about this and wait 
until someone tackles the real cause of the problem? We shouldn't have to do 
any inflating, be it by 1, twipsPerPx/2 or 20. I could possibly be convinced 
that 1 is plausible. Using twipsPerPx/2 would just obscure the fact that it is 
a magic number.

I have a feeling that somehow the *real* problem might be connected with us 
nudging the dirty rects in nsSVGOuterSVGFrame::InvalidateRegion(). That 'int 
twipsPerPx = (int)(GetTwipsPerPx()+0.5f);' on line 898 looks highly suspect :-)
Hmm. OK, I guess. r=bbaetz; not sure if you need drivers@m.o approval to land it.

Yes, that code does look strange. Why is it there?

Comment 9

17 years ago
> I have a feeling that somehow the *real* problem might be connected with us 
> nudging the dirty rects in nsSVGOuterSVGFrame::InvalidateRegion(). That 'int 
> twipsPerPx = (int)(GetTwipsPerPx()+0.5f);' on line 898 looks highly suspect :-)

What would happen if we changed that? Somehow I get the feeling that was also
put there because of an ugly hack. :-)

Comment 10

16 years ago
Created attachment 89785 [details]
Randomly scattered dots (small circles), misrendered

Having a stroke-width more than double the radius of the circle seems to cause
horizontal lines, but not always.

Comment 11

16 years ago
Created attachment 89794 [details]
Counter example to above attachment

This is a counter example with circles at the same points, with the same
radius, but narrower stroke-widths.  None of these produce the horizontal line.
Mass reassign of SVG bugs that aren't currently being worked on by Alex to
general@svg.bugs. If you think someone should be assigned to your bug you can
join the #svg channel on mozilla.org's IRC server ( irc://irc.mozilla.org/svg )
where you can try to convince one of the SVG hackers to work on it. We aren't
always there, so if you don't get a response straight away please try again later. 
Assignee: dean.jackson → general

Comment 13

13 years ago
WFM 

(Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051025 Firefox/1.5)

Comment 14

13 years ago
I can see this problem on the test case attached.
But I can not see this problem on this.
http://skeeter-s.com/svg/new-svg.xml
I am on solaris by the way.
Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.9a1) Gecko/20051021 Firefox/1.6a1
The problem persists despite the switch to cairo. Still seeing it in FF1.5 and latest trunk on w32.
OS: Linux → All

Comment 16

12 years ago
WFM

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20061023 SUSE/2.0-30 Firefox/2.0

and

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0

Updated

12 years ago
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.