148685 - Text in form popups rendered too "bold" with rougher anti-aliasing

Status: VERIFIED FIXED

(Camino Graveyard :: Page Layout, defect)

Description

[Philip Timmermann]

Text in Cycle-Gadgets appears too "bold" and with rougher anti-aliasing 
than text in other areas... If you look close, you are able to see that the 
rendered text actually appears to have the same "boldness" and height, 
but it looks like it is being rendered with odd gamma or rendered two 
times above itself (which causes the transparent anti-aliasing pixels to 
multiply themselves darker)... I know this description and my English 
aren't the best... I'll throw a little visualization together in Photoshop and 
attach it to this bug... ;-)

P.S.: This bug was originally filed on mozdev.org as #1176

Comment 1

[Philip Timmermann]

Attachment: a little demonstration of the problem thrown together in Photoshop...

Comment 2

[Greg K.]

Philip, you should probably find some Aqua control with bold text in another app
and compare it to the one you see in Chimera.

Comment 3

[Philip Timmermann]

Greg, I don't think the text in the Cycle-Gadget is just bold-style. In fact it is 
regular-style but either "drawn" multiple times above itself ("multiply"-ing 
its "anti-alias"-ing darker) or drawn with darker "anti-alias"-ing in the first 
place for whatever reason.

Making text bold-style would increase its width.

...and why draw it bold in the first place? Apple doesn't do bold text in 
Cycle-Gadgets as far as I know... and it simply isn't just bold text...

I'll throw together another small illustration which proves this...

Comment 4

[Philip Timmermann]

Attachment: another little demonstration of the problem thrown together in Photoshop...

Comment 5

[Greg K.]

Philip, you should be aware that Chimera isn't doing the antialiasing itself;
Mac OS X does that.

Comment 6

[Philip Timmermann]

Greg, If this is the case, then maybe the text really is just "written" two (or more) times 
exactly above itself. The result of doing something like this looks almost precisely like 
what happens in Chimera (what I illustrated in the attachments).

I don't know exactly what causes this, but as Chimera is the only program acting like this, 
I'm not sure it's all OS X's fault.

Actually I'm pretty sure it in fact is Chimera's fault, but I have no more arguments in my 
sleeve to back this up, except for the stuff I already wrote... ;-)

Comment 7

[Greg K.]

Philip, I can also reproduce the problem in BBEdit 6.1.2 with Silk active.
Typing in 14 pt. Monaco, the text is heavier than normal until I hit the delete
key once.

If you don't have BBEdit, perhaps it happens in other Carbon
non-Quartz-Smoothing apps, too.

Comment 8

[Simon Fraser [no longer active]]

This is concerned with Pink's "native" form controls (although Gecko uses Gfx to
draw the text). ->pinkerton

Comment 9

[Mike Pinkerton (not reading bugmail)]

hyatt did the form controls, not me --> bryner

Comment 10

[Philip Timmermann]

Hmmm... Reading about "paint twice" issues in form-elements in bug 164234
reminded me a lot of what I wrote here about text looking like its being drawn two
times above itself...

Comment 11

[monkeypox37]

Re: similarity of bug 164234 to 148685

These are two different things. Bug 164234 is concerned with the region being
drawn by Chimera when scrolling. In 10.2 the graphics card is finally used to
accelerate scrolling - that means it moves the scroll region and then Chimera
should paint in new content only (compared to 10.1.x where the entire scroll
region was repainted). Form elements seem to cause the area that Chimera
repaints to become messed up and so it re-draws parts of the window that don't
need to be done.

FWIW I haven't been following 148685, but if you use Quartz Debug and turn on
the 'Autoflush drawing' and 'Flash screen updates (yellow)' checkboxes it'll
draw the button slowly enough that you can see what's going on.

Comment 12

[Simon Fraser [no longer active]]

This bug happens because nsComboboxControlFrame::Paint() paints its children
twice. The call to 

      nsAreaFrame::Paint(aPresContext, aRenderingContext, aDirtyRect,
                       NS_FRAME_PAINT_LAYER_FLOATERS);

paints them once, then, just below, the call to 

      PaintChild(aPresContext, aRenderingContext, aDirtyRect, 
                 mDisplayFrame, NS_FRAME_PAINT_LAYER_FOREGROUND);

paints them again.

Comment 13

[Simon Fraser [no longer active]]

Attachment: Patch to comment out the explicit drawing of mDisplayFrame

This patch just comments out the lines that call PaintChild() on mDisplayFrame,
since the nsAreaFrame::Paint() calls will have drawn that frame anyway. The
entire 'draw focus' block was included in the commented out portion, because it
didn't do any drawing anyway.

Comment 14

[Simon Fraser [no longer active]]

Ping? anyone? I'm temped to just check this in.

Comment 15

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 106122 [details] [diff] [review]
Patch to comment out the explicit drawing of mDisplayFrame

r=pink

how about instead of commenting it out you #ifdef it with something
intelligent?

Comment 16

[Simon Fraser [no longer active]]

Fix checked in.