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.

Opacity lower than 1 causes text anti-aliasing/rendering issue

VERIFIED WORKSFORME

Status

Camino Graveyard
Page Layout
--
minor
VERIFIED WORKSFORME
10 years ago
10 years ago

People

(Reporter: Michiel Sikma, Unassigned)

Tracking

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:1.8.1.13) Gecko/20080327 Camino/1.6b4 (like Firefox/2.0.0.13)
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:1.8.1.13) Gecko/20080327 Camino/1.6b4 (like Firefox/2.0.0.13)

When a page contains a visible element with an opacity lower than 1, all of the text that's rendered in the initial viewable area will have a different type of anti-aliasing on Mac OS X 10.4 and Mac OS X 10.5 (both with latest updates).

Take a look at the URL I included: the page looks fine. Then click the link to the transparent version: the text will look "thinner" and won't have sub-pixel anti-aliasing.

When this occurs on a page that's scrollable, scrolling down will make the rest of the text on the page appear normal.  Also, when selecting the affected text, it will be redrawn with the proper anti-aliasing.

Reproducible: Always

Steps to Reproduce:
1. Open a page with a transparent element.
2. To see properly drawn text outside of viewable area, simply scroll down if possible.
3. To see properly redrawn affected text, select it.
Actual Results:  
After step 1, the page contained improperly rendered text in the initial viewable area.  After step 2, the page showed some improperly rendered text (the text that was visible before scrolling) and some properly rendered text (all the text that was not visible before scrolling down to see it).  After step 3, the lines of text I had selected were properly rendered.

Expected Results:  
The software should have drawn all text properly to begin with.

Happens on several systems.  I haven't tested it on that many systems, but several versions of Camino (including this one) on both the latest Mac OS X 10.4 and Mac OS X 10.5 have this issue.

Comment 1

10 years ago
Can you put together a reduced testcase, please, and then test it in Firefox 2 and the latest Firefox 3 beta as well?

All the text-rendering code is in Core, so Camino and Firefox should be equally affected.

This sounds somewhat like bug 363861, though I can't say for sure if it's a dupe.

Comment 2

10 years ago
Oh, and screenshots -- zoomed in if necessary -- would be useful, too.

Comment 3

10 years ago
By the way, the two pages you've provided look exactly the same in a Camino trunk nightly and the Firefox 3 beta I have here (I think it's 3.0b1), which makes me think this was FIXED by the landing of Cairo in Core.

If someone wants to figure out whether or not this is really a dupe of one of those bugs, go right ahead. Otherwise I think it's safe to call this either FIXED or WORKSFORME on trunk.

Michiel, this will probably never work properly on the current branch (Camino versions prior to 2.0, and Firefox versions prior to 3.0).

Comment 4

10 years ago
yeah, there are absolutely no problems with this on trunk (Gecko 1.9, Camino 2.0a1, Fx 3pre). Thanks Cairo and Atsui.
On branch (both Camino 1.6rc1 and Fx 2.0.0.x), this happens due to the way text is painted is painted on screen. Depending on font-size and font-family used in the documents - and the way opacity is implemented in Gecko1.8, it is more or less visible.

I didn't find any previous bug about this, but WFM on trunk is safe, I think.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 5

10 years ago
Created attachment 315352 [details]
A screenshot that shows the error.
(Reporter)

Comment 6

10 years ago
I'm glad that this is probably fixed.  I just uploaded an attachment that shows the error, just in case.

Comment 7

10 years ago
What you also see in your screenshot is that in the element with opacity applied, the text is grey (faded). That is the correct behaviour. Opacity is applied to the whole box; it is not a way to make the background of the box semi-translucent. The whole box (border+background+content) and all its descendants is make semi-translucent.
See
http://www.w3.org/TR/css3-color/#transparency

it is the fading that makes the anti-aliasing of text sometimes less than optimal in Gecko 1.8.

(Reporter)

Comment 8

10 years ago
Yes, the contents of the box are supposed to be transparent.  That's correct behavior and logical as well.

But that's actually not what this is about.  This is about the rest of the text (outside of the transparent box) being grey and "thin" as well.  Compare the two: the text on the right looks much "thinner", and, upon further inspection, does not have sub-pixel anti-aliasing.  It's the text rendering that's the issue here.

Updated

10 years ago
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.