Closed Bug 928727 Opened 11 years ago Closed 11 years ago

awful scrolling side-effect on last nightly : flickering black rectangles over content

Categories

(Core :: Graphics, defect)

x86
All
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla27
Tracking Status
firefox27 + verified

People

(Reporter: goofy.bugzilla, Assigned: mattwoodrow)

References

Details

(Keywords: regression, Whiteboard: [bugday-20131021])

Attachments

(2 files)

Mozilla/5.0 (X11; Linux i686; rv:27.0) Gecko/20100101 Firefox/27.0 this is my current build http://hg.mozilla.org/mozilla-central/rev/0d316980f21f (just updated nightly for linux 32 / French version very annoying behaviour Whenever I use the scroll bar (or even go to next line on this very from field striking the ENTEr key) There is a nasty visual annoyance which can be described aa a flickering black horzontal rectangle. am obliged to downgrade my Firefox for my eyes' sake :s exected scrooling smoothly without visual unwanted interference I don't think I exagerate when filing this as critical for the user.
I encounter the same bug (Nightly linux 64 / French too) Florent
I'm also affected. Yesterday's nightly is fine so something from http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e25e62d174ed&tochange=0d316980f21f
For the record, this seems related to Azure: if I turn gfx.content.azure.enabled to false in about:config, I can scroll without visual annoyance (Nightly 64 on Debian GNU/Linux with fluxbox)
(In reply to Clochix from comment #3) > For the record, this seems related to Azure: if I turn > gfx.content.azure.enabled to false in about:config, I can scroll without > visual annoyance (Nightly 64 on Debian GNU/Linux with fluxbox) tricky fix confirmed for me
I'm seeing something similar on XP: flicker mainly when I switch to image tabs, and when mousing over some XUL elements. I don't see anything while scrolling though. Enabling acceleration seems to make the flicker go away, as does disabling Azure with the pref in comment 3.
The artifacts appear on any repaint--scrolling, switching tabs, uncovering the window. There are even black boxes appearing on the scroll bar when I just move my mouse over the scroll bar. Clean profile yada yada yada. Disabling Azure does fix the problem.
> For the record, this seems related to Azure: if I turn gfx.content.azure.enabled to false in about:config, I can scroll without visual annoyance (Nightly 64 on Debian GNU/Linux with fluxbox) Works for me too (after a Nightly restart), thanks!
I have the same bug on Windows 7 SP1 64 bit. (Changing the aforementioned pref. also makes it go away)
bug 928758 comment 0 by Alice0775 has a regression window and: Regressed by: fc7cc3c1dccf Benoit Girard — Bug 928123 - Avoid PushGroup during simple FillRect. r=Bas
Blocks: 928123
Component: General → Graphics
Keywords: regression
OS: Linux → All
Product: Firefox → Core
Whiteboard: [bugday-20131021]
Version: unspecified → Trunk
Attachment #819724 - Flags: review?(jmuizelaar)
Attached patch Remove unnecessary clears (deleted) — Splinter Review
This bug happens because we are drawing a ThebesLayer directly to the window using OPERATOR_SOURCE. We need this to happen in a single atomic operation, because windows can choose to present our contents at any time. We were clearing and then drawing in two separate steps, so it was possible to get the intermediate state presented, which shows up as black flashes. Removing the clear (which should be unnecessary) should fix the issues. The first clear is clearing the surface created by push_group, which is always initialized to be transparent. The second clear would only have effect if we're using OPERATOR_SOURCE, and we can only get to this point in the path bounds entirely cover the clip (aPathBoundsClip == true). In this case clearing is unnecessary since bounded and unbounded are identical in this case.
Attachment #819728 - Flags: review?(jmuizelaar)
Assignee: nobody → matt.woodrow
Status: NEW → ASSIGNED
Attachment #819724 - Flags: review?(jmuizelaar) → review+
Attachment #819728 - Flags: review?(jmuizelaar) → review+
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla27
Requesting koi? because I want to land bug 928123 and will need these regression fixes.
blocking-b2g: --- → koi?
Alright we don't need koi for this because moz2d isn't enabled there. This means that koi isn't impacted by this bug so it doesn't matter.
As the (civilian) originator of duplicate bug 928772 I confirm that the most recent 27.0a1 (2013-10-23) no longer suffers from this problem.
Moving to 1.3? per comment 18
blocking-b2g: koi? → 1.3?
Already in 1.3, clearing nom.
blocking-b2g: 1.3? → ---
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 Mozilla/5.0 (X11; Linux i686; rv:27.0) Gecko/20100101 Firefox/27.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:27.0) Gecko/20100101 Firefox/27.0 Verified as fixed on Firefox 27 beta 5 (20140109165205).
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: