91816 - bullets are not displayed correctly on certain text zooms

Status: RESOLVED FIXED

(Core Graveyard :: GFX, defect)

Description

[Shaji]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2+) Gecko/20010720
BuildID:    2001072008

The bullets are displayed with a square and two lines projecting out of it. This
does make it look ugly. Screenshot of magnified image is attached.


Reproducible: Always

Comment 1

[Shaji]

Attachment: Magnified image of the bullets in http://slashdot.org

Comment 2

[Jason Johnston]

This is probably a fonts issue.  Looks just fine on Win32.

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

We just call nsRenderingContextGTK::FillEllipse which calls gdk_draw_arc.  Is
that not optimal?

->Compositor

Comment 4

[Christopher Aillon (sabbatical, not receiving bugmail)]

Confirming linux only.  (2001072621)

Comment 5

[Kevin McCluskey (gone)]

Using todays trunk build on Linux I don't see any lines projecting out of the
bullets on slashdot.  I also brought up composer and added some bulleted items
and I don't see any lines protruding.

Marking WFM.

Comment 6

[Shaji]

If I change the zoom to 90% or 120% works for me too. I think the problem occurs
with some fonts/some size. So try changing your font or zoom level.

Comment 7

[Shaji]

I have tested this with 0.9.5. The problem is still there. Reopening the bug.

Comment 8

[Christopher Aillon (sabbatical, not receiving bugmail)]

Updating url to the same as the testcase.

On linux 2001101212 i can still confirm this.  However, it is fine for me at
100%, but zooming to 120% I see the problem

Comment 9

[manly+bugzilla]

Confirmed at 120% zoom on build 2001103012/Linux

Comment 10

[Shaji]

I have some more clues on the problem:

1. The problem with slashdot goes away when I used helvetica instead of ttf
fonts like arial/verdana as my default font setting.
2. On sites which have bullets and specify fonts (arial/verdana) the problem
appears (even after changing my default fonts to helvetica)

So I am changing the test URL.

Comment 11

[Shaji]

Attachment: Test case displaying the bug

Comment 12

[Shaji]

I have seen this problem on Windows 2000 too. Use some tool to magnify the
screen. And you can see the problem there too. Once good thing about Windows is
that the problem is not clearly visible to the "naked eye", you need a magnifier
to see the problem.

Comment 13

[Shaji]

Attachment: Bullets in both IE and Mozilla on Windows 2000

Comment 14

[Christopher Aillon (sabbatical, not receiving bugmail)]

*** Bug 118844 has been marked as a duplicate of this bug. ***

Comment 15

[Jeremy M. Dolan]

Attachment: NS4.7 vs Mozilla on Linux

"Future" is a long time away. This occurs on all pages for the first level <li>
bullet for me. NOTE however, that the second level, the circle (unfilled), is
PERFECTLY round. The screencap demonstrates this.

Can someone please take a look at this differances between how disc/circle are
rendered? It doesn't appear to be a platform GFX issue (gdk_arc) as suggested
before as the last comment showed it happening on Win2000, though not as bad.

Comment 16

[Jeremy M. Dolan]

This is a longshot, but a guess at the cause.

Perhaps, are we drawing the circle with a radius of x, then do fill it, drawing
a filled square of the same (or too close to the same the rounding makes it the
same) radius?

I ask because my screenshot clearly shows the disc is a perfect square (from the
fill), with two pixels sticking out (from the circle draw, rounding error).

I also seem to remember seeing at lots of places, the first bullet being square.
Now it's possible LOTS of sites are setting the <li> style, but doubtful.

Comment 17

[Christopher Aillon (sabbatical, not receiving bugmail)]

*** Bug 120249 has been marked as a duplicate of this bug. ***

Comment 18

[Boris 'pi' Piwinger]

Attachment: Screenshot: disc as a real square

This is a screenshot (http://piology.org/hotlist/computer.html#programs), the
left part shows it magnified, the right the original size. Different from the
previous, this is a real square, no lines pointing up and left. Going to 120%
to 150% adds those lines. At 200% it really becomes a disc.

pi

Comment 19

[Shaji]

This appears to be a known problem with gdk_draw_arc(). The solution is to draw
an outline of the circle as described in:

http://developer.gnome.org/doc/GGAD/z132.html

"Many X servers draw the edges of filled arcs in an aesthetically unpleasing
way; in particular, very small circles may not look very circular. You can work
around this by also drawing the circle's outline."

A sample code is in:

http://mail.gnome.org/archives/gtk-list/1999-May/msg00528.html


The fix for mozilla would be to add an outline in nsRenderingContextGTK.cpp. I
have made this change and tried it out - it works fine. The cvs diff is:

Index: gfx/src/gtk/nsRenderingContextGTK.cpp
===================================================================
RCS file: /cvsroot/mozilla/gfx/src/gtk/nsRenderingContextGTK.cpp,v
retrieving revision 1.151
diff -r1.151 nsRenderingContextGTK.cpp
1107a1108,1110
>   ::gdk_draw_arc(mSurface->GetDrawable(), mGC, FALSE,
>                  x, y, w, h,
>                  0, 360 * 64);

(it just draws an unfilled circle before drawing the filled ellipse)

I do not know how to create a patch, but since the change is really small, I
guess it is not required. Can someone apply this and test it ?

Comment 20

[Shaji]

Attachment: Patch file

Comment 21

[Christian Reis]

Can we unfuture this as we now have a patch? Any testers available?

Comment 22

[Stuart Parmenter]

Comment on attachment 66670 [details] [diff] [review]
Patch file

r=pavlov

Comment 23

[Christian Reis]

Marking 0.9.9 as it has review. 

Comment 24

[Shaji]

Can anyone sr= this patch?

Comment 25

[Mike Shaver (:shaver emeritus)]

Comment on attachment 66670 [details] [diff] [review]
Patch file

sr=shaver.

Comment 26

[Boris Zbarsky [:bzbarsky]]

checked into tip.  Begone, foul drawing of bullets!

Comment 27

[Jeremy M. Dolan]

With this patch, it's improved, however, still a few issues. 4.x - since it
didn't zoom - only had one way to draw bullets. It was a 5x5 square, with 1px
removed from all four corners. This ends up looking surprisingly round.

I took screencaps at 6 differant zoom levels of the bullets in Moz:

  http://turbogeek.org/mozilla/bullet-zooms.png

The 75% and 90% bullets are 4.x style... 5x5 - 4 px. 100% and above have a
larger radius, which requries a differant modification to the corners, in terms
of pixels. All four of those end up looking diamond-like (when you're not zoomed
in on them).

Here is a normal screencap, 100% zoom:

  http://turbogeek.org/mozilla/bullet-relative.png

I would like to see the circle drawing calculations adjusted so that at 100%, I
still get the 5x5-4px circle. The current one shown looks too big first of all,
and it's too low. It extends all the way down to the bottom of the line with the
letters.

As far as my setup, XFree 4.1, with Mozilla set to get DPI from the server.

screen #0:
  dimensions:    1152x864 pixels (361x271 millimeters)
  resolution:    81x81 dots per inch

The 81x81 is from PnP, and dead accurate, according to my own manual calculations.

Comment 28

[Christian Reis]

Proper process would be to file a new bug; owner can decide if he wants to fix
this here or not. It does look much better now AAR. :)

Comment 29

[Shaji]

Attachment: Circles with radius 2-10 drawn by gtk

I dont think anything could be done further to make all bullets look like
circles. See the attachment, this is how gtk draws circles(filled and empty)
with radius 2-10 pixels. May be there is some other way of drawing circles, but
at least the ones drawn are not ugly as it was before.

Comment 30

[Roland Mainz]

Reopening bug for an optimisation...

Comment 31

[Roland Mainz]

Taking...

The current version draws always twice - which is AFAIK not neccesary.

Comment 32

[Roland Mainz]

Attachment: Patch for 2002-02-20-08-trunk

Changes:
- Added a check which only draws the arc along the filled arc when either width
or height are smaller than 16 pixels
- Added comment and reference to this bug

Fixes:
- Avoids drawing the arc even when the size of the filled arc is large enougth
- Avoids triggering a Xprt PS DDX bug when drawing arcs, filled arcs and text
in certain combinations

Comment 33

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 70691 [details] [diff] [review]
Patch for 2002-02-20-08-trunk

>+  if ((w < 16) || (h < 16)) {

get rid of those extra parenthesis around the comparisons.

r=bzbarsky with that change

Comment 34

[Roland Mainz]

Attachment: Better patch for 2002-02-20-08-trunk per bz's comments

Comment 35

[Marc Attinasi]

Comment on attachment 70694 [details] [diff] [review]
Better patch for 2002-02-20-08-trunk per bz's comments

sr=attinasi

Comment 36

[Mike Shaver (:shaver emeritus)]

Comment on attachment 70694 [details] [diff] [review]
Better patch for 2002-02-20-08-trunk per bz's comments

a=shaver for 0.9.9.

Comment 37

[Boris Zbarsky [:bzbarsky]]

Checked in on trunk for 0.9.9

Comment 38

[Boris Zbarsky [:bzbarsky]]

and fixed, even.  :)