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)
Tracking
()
VERIFIED
FIXED
mozilla27
People
(Reporter: goofy.bugzilla, Assigned: mattwoodrow)
References
Details
(Keywords: regression, Whiteboard: [bugday-20131021])
Attachments
(2 files)
(deleted),
patch
|
jrmuizel
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
jrmuizel
:
review+
|
Details | Diff | Splinter Review |
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.
Comment 1•11 years ago
|
||
I encounter the same bug (Nightly linux 64 / French too)
Florent
Comment 2•11 years ago
|
||
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)
Reporter | ||
Comment 4•11 years ago
|
||
(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
Comment 5•11 years ago
|
||
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.
Comment 6•11 years ago
|
||
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.
Comment 7•11 years ago
|
||
> 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)
Comment 10•11 years ago
|
||
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
Assignee | ||
Comment 11•11 years ago
|
||
Attachment #819724 -
Flags: review?(jmuizelaar)
Assignee | ||
Comment 12•11 years ago
|
||
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 | ||
Updated•11 years ago
|
Assignee: nobody → matt.woodrow
Updated•11 years ago
|
Status: NEW → ASSIGNED
Updated•11 years ago
|
status-firefox27:
--- → affected
tracking-firefox27:
--- → +
Updated•11 years ago
|
Attachment #819724 -
Flags: review?(jmuizelaar) → review+
Updated•11 years ago
|
Attachment #819728 -
Flags: review?(jmuizelaar) → review+
Assignee | ||
Comment 14•11 years ago
|
||
Comment 16•11 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/a047800e4772
https://hg.mozilla.org/mozilla-central/rev/5a7016b24bf8
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla27
Comment 17•11 years ago
|
||
Requesting koi? because I want to land bug 928123 and will need these regression fixes.
blocking-b2g: --- → koi?
Comment 18•11 years ago
|
||
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.
Comment 19•11 years ago
|
||
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.
Comment 23•11 years ago
|
||
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.
Description
•