Closed Bug 654641 Opened 13 years ago Closed 13 years ago

After scroll pull-down, font becomes thin for 2-3 seconds.. Maybe anti aliasing issue.

Categories

(Core :: Graphics, defect)

x86
Windows 7
defect
Not set
minor

Tracking

()

VERIFIED FIXED
mozilla6

People

(Reporter: alice0775, Assigned: roc)

References

Details

(Keywords: regression)

Attachments

(2 files)

Attached image screenshot
Build Identifier:
http://hg.mozilla.org/releases/mozilla-2.0/rev/9b8188993c1a
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.2pre) Gecko/20110501 Firefox/4.0.2pre ID:20110501030621
http://hg.mozilla.org/mozilla-aurora/rev/308693ad3772
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110413 Firefox/5.0a2 ID:20110503042003
http://hg.mozilla.org/releases/mozilla-2.0/rev/9b8188993c1a
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.2pre) Gecko/20110501 Firefox/4.0.2pre ID:20110501030621

After scroll pull-down, font becomes thin for 2-3 seconds..
Maybe anti aliasing issue.

Reproducible: Always

Steps to Reproduce:
1. Start Firefox with new profile
2. Open ( ex. https://bugzilla.mozilla.org/userprefs.cgi )
4. Page Zoom-In Ctrl++ repeats 5 times (In order to make easy to verify the bug)
5. Open pull-down "Timezone used to display dates and times"
6. Scroll the pull-down and watch the font for a while

Actual Results:
 After scroll pull-down, font becomes thin for 2-3 seconds.


Expected Results:
 Font appearance should be same .
Probably something with layers going active/inactive. Not sure if this is a bug.
layers.acceleration.disabled=true does not fix.
But, gfx.direct2d.disabled=true helps.

Default preferences:
Graphics
  Adapter Description: ATI Radeon HD 4300/4500 Series
  Vendor ID: 1002
  Device ID: 954f
  Adapter RAM: 512
  Adapter Drivers: aticfx64 aticfx64 aticfx32 aticfx32 atiumd64 atidxx64 atiumdag atidxx32 atiumdva atiumd6a atitmm64
  Driver Version: 8.841.0.0
  Driver Date: 4-5-2011
  Direct2D Enabled: true
  DirectWrite Enabled: true (6.1.7601.17563, font cache n/a)
  WebGL Renderer: Google Inc. -- ANGLE -- OpenGL ES 2.0 (ANGLE 0.0.0.611)
  GPU Accelerated Windows: 1/1 Direct3D 10
Severity: normal → minor
Regression window(cached m-c hourly):
Works:
http://hg.mozilla.org/mozilla-central/rev/67ee5b40edd5
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b13pre) Gecko/20110222 Firefox/4.0b13pre ID:20110222201727
Fails:
http://hg.mozilla.org/mozilla-central/rev/b8194445b364
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b13pre) Gecko/20110222 Firefox/4.0b13pre ID:20110222214147
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=67ee5b40edd5&tochange=b8194445b364

Candidate:
b8194445b364	Robert O'Callahan — Bug 630835. Make BuildLayer responsible for setting a visible region on the layer, and let FrameLayerBuilder only reduce it. r=tnikkel,a=blocking This avoids problems with FrameLayerBuilder making the visible region bigger than we expected, invalidating CONTENT_OPAQUE flags set on the layer. In particular, we had been using TransformBounds to compute the new visible region, and for non-axis-aligned transforms this gives us a visible region which contains areas not actually painted by the layer contents.
Blocks: 630835
Keywords: regression
Manual antialiasing due to us deciding that some layer is transparent, probably...
Is there a bug for fixing the gamma correction issues there?
Attached patch fixSplinter Review
Eh, I can just fix this.

The reason we have this problem is that the nsDisplaySolidColor at the root of the select has a fractional pixel width. So the ThebesLayer it goes into gets a visible region that's the rounded-out width, but the nsDisplaySolidColor only opaquely covers the rounded-in width.

This patch fixes the problem by making nsDisplaySolidColor::GetBounds return the snapped bounds when appropriate, like nsDisplayBackground does.
Assignee: nobody → roc
Attachment #529932 - Flags: review?(tnikkel)
Attachment #529932 - Flags: review?(tnikkel) → review+
Whiteboard: [needs landing]
Pushed:
http://hg.mozilla.org/mozilla-central/rev/1da21b25c5e0
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [needs landing]
Target Milestone: --- → mozilla6
Comment on attachment 529932 [details] [diff] [review]
fix

Ugly regression in Firefox 4, fairly safe fix.
Attachment #529932 - Flags: approval-mozilla-aurora?
How widespread is this likely to be on the Web and how likely is this to be obvious to users without the 5x zooming. I realize that the steps to reproduce are in order to exaggerate the problem to make it easier to identify, but what I don't understand is whether or not this is a big problem for users in the wild who aren't zooming in 5x.

I'm leaning towards a no on taking this into Beta. (Would we have taken this into Firefox 4 RC?)
Zooming doesn't affect it, for me; I can see it without zooming. It looks ugly. It's probably less important than my other approval requests though :-).
Comment on attachment 529932 [details] [diff] [review]
fix

Not taking this in the Fx5 beta period.
Attachment #529932 - Flags: approval-mozilla-aurora? → approval-mozilla-beta-
Setting resolution to Verified Fixed on Mozilla/5.0 (Windows NT 6.1; rv:6.0) Gecko/20100101 Firefox/6.0
Status: RESOLVED → VERIFIED
Machine: Win7 Pro 32bit, Ati Mobility Radeon x1400 (10.2 legacy driver)

This problem still appears on some pages. A sample page where i encounter it: dubstep.fm/chat. There is Mibbit IRC chat. If I scroll or the chat has a new entry then everything becomes thin for a few seconds, when undisturbed it returns to normal. Problem with FF4 to FF6.

About:support says "Direct2D Enabled (Blocked for your graphics driver version. Try updating your graphics driver to version 10.6 or newer.)"
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: