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

VERIFIED FIXED in Firefox 27

Status

()

defect
--
critical
VERIFIED FIXED
6 years ago
6 years ago

People

(Reporter: goofy.bugzilla, Assigned: mattwoodrow)

Tracking

({regression})

Trunk
mozilla27
x86
All
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox27+ verified)

Details

(Whiteboard: [bugday-20131021])

Attachments

(2 attachments)

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
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)
Duplicate of this bug: 928758
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)
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
Duplicate of this bug: 929053
Attachment #819724 - Flags: review?(jmuizelaar) → review+
Attachment #819728 - Flags: review?(jmuizelaar) → review+
Duplicate of this bug: 928772
https://hg.mozilla.org/mozilla-central/rev/a047800e4772
https://hg.mozilla.org/mozilla-central/rev/5a7016b24bf8
Status: ASSIGNED → RESOLVED
Closed: 6 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?
Duplicate of this bug: 929425
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.