annoying black flicker on menus and dropdowns

RESOLVED FIXED in mozilla12

Status

()

Core
Graphics
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: Stefan, Assigned: karlt)

Tracking

({regression})

Trunk
mozilla12
x86_64
Linux
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

6 years ago
User Agent:  

Steps to reproduce:

1. Focus on a tab.
2. Repeat the sequence "Menu-Key*, ESC" rapidly (e.g. 2/s)

Alternatively invoke the tab's menu by a right click.

*) http://en.wikipedia.org/wiki/Menu_key


Actual results:

2. Flicker: A black rectangle is painted before the context menu appears which.


Expected results:

2. No flicker.

last good nightly 2011-01-24-03-mozilla-central 80266029824b
first bad nightly 2011-01-25-03-mozilla-central 6a097e294828

The first bad revision is:
changeset: 61193:e874889e43d1
user: Ehsan Akhgari <ehsan@mozilla.com>
date: Fri Jan 21 16:45:23 2011 -0500
summary: Bug 579374 - Clear cached resources for GTK windows when we hide/destroy them; r=roc a=blocking-final+
(Reporter)

Updated

6 years ago
OS: Other → Linux
Hardware: Other → x86_64
Summary: annoying flicker on tab content menu → annoying flicker on tab context menu

Updated

6 years ago
Depends on: 579374
Component: General → Widget: Gtk
Product: Firefox → Core
QA Contact: general → gtk
Maybe we should be doing ClearCachedResources at the end of nsWindow::Show?
I wasn't able to reproduce.

Stefan, you seem to be proficient in doing your own builds? Could you try moving this http://mxr.mozilla.org/mozilla-central/source/widget/src/gtk2/nsWindow.cpp#1086 ClearCachedResources call to the end of nsWindow::Show?
(Assignee)

Comment 3

6 years ago
Thanks very much for the regression window.
Which window manager is in use?  Is compositing enabled?
(Reporter)

Comment 4

6 years ago
 (In reply to Timothy Nikkel (:tn) from comment #2)
> Stefan, you seem to be proficient in doing your own builds? Could you try
> moving this
> http://mxr.mozilla.org/mozilla-central/source/widget/src/gtk2/nsWindow.
> cpp#1086 ClearCachedResources call to the end of nsWindow::Show?

The flicker goes but then the tooltip border issue of Bug 579374 is back.

(In reply to Karl Tomlinson (:karlt) from comment #3)
> Which window manager is in use?

KDE 3.5

> Is compositing enabled?

Do you mean "Compositing" in xorg.conf? Then it is disabled.
(Assignee)

Comment 5

6 years ago
I think I can reproduce something similar with compositing disabled.
(I'm using kwin 4.7, but the window manager should not be involved if compositing is enabled.)

If I click on the location bar dropdown button quickly several times, then sometimes
I see a black rectangular flash across the full width of the dropdown, but covering only a fraction of the vertical distance (and presumably depends on timing with vrefresh).

Under kwin, the initial state of compositing is controlled via System Settings -> Desktop Effects -> Enable desktop effects at startup.  If supported, it can be toggled with Alt+Shift+F12, but, if "xdpyinfo | grep Composite" doesn't find Composite, then window compositing won't be available.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 6

6 years ago
According to

> "xdpyinfo | grep Composite"

the "Composite" extension actually IS active. Nontheless disabling it (explicit "Composite" "Disabled" in xorg.conf) does NOT mitigate the flicker here.
(Assignee)

Comment 7

6 years ago
Created attachment 584720 [details]
stack of black paint

We're painting the whole window black because we are drawing from the buffer for a layer with an empty valid region during an incomplete empty layer manager transaction.
(Assignee)

Updated

6 years ago
Component: Widget: Gtk → Graphics
QA Contact: gtk → thebes
I think that would be what we would expect if we got a paint event for a window that has had ClearCachedResources called on it. Why would we get such a paint though?
(Assignee)

Updated

6 years ago
Keywords: regression
Summary: annoying flicker on tab context menu → annoying black flicker on menus and dropdowns
(Assignee)

Comment 9

6 years ago
(In reply to Timothy Nikkel (:tn) from comment #8)
It has been shown again.
Ah, ok. So it must be an invalidate after drawing the black and then it draws correctly? When does that happen?
(Assignee)

Comment 11

6 years ago
During EndEmptyTransaction, it looks like PaintBuffer is designed to do
nothing more than mark the empty tranaction incomplete.  This will ensure that
EndEmptyTransaction returns false and so a non-empty transaction will
immediately take place (and this draws correctly).

However the black paint during the empty transaction is happening directly on the
window (because double buffering is not necessary).  I don't know why
PaintThebes is still drawing the buffer (which is invalid and black) even
though it knows the transaction is incomplete.
(In reply to Karl Tomlinson (:karlt) from comment #11)
> I don't know why
> PaintThebes is still drawing the buffer (which is invalid and black) even
> though it knows the transaction is incomplete.

No good reason. Please fix that!
(Assignee)

Updated

6 years ago
Assignee: nobody → karlt
(Assignee)

Comment 13

6 years ago
Created attachment 585656 [details] [diff] [review]
don't draw from BasicThebesLayerBuffers when transaction is incomplete

Looks like we still need to BasicShadowableThebesLayer::PaintBuffer() even
with a null aCallback in order to process PaintState::mDidSelfCopy.
Attachment #585656 - Flags: review?(roc)
(Reporter)

Comment 14

6 years ago
(In reply to Karl Tomlinson (:karlt) from comment #13)
> Created attachment 585656 [details] [diff] [review]
> don't draw from BasicThebesLayerBuffers when transaction is incomplete

Works. Thx.
Comment on attachment 585656 [details] [diff] [review]
don't draw from BasicThebesLayerBuffers when transaction is incomplete

Review of attachment 585656 [details] [diff] [review]:
-----------------------------------------------------------------

Better to add an IsTransactionIncomplete() getter to BasicLayerManager, and call it to do an early return before "if (!IsHidden())". I think that will be a bit more clear. Also more robust since we won't be relying on state.mContext being null if there's no invalid area.
(Assignee)

Comment 16

6 years ago
Comment on attachment 585656 [details] [diff] [review]
don't draw from BasicThebesLayerBuffers when transaction is incomplete

OK.  That would be safer wrt behaviour changes in the other methods.
Attachment #585656 - Flags: review?(roc)
(Assignee)

Comment 17

6 years ago
Created attachment 585871 [details] [diff] [review]
don't draw from BasicThebesLayerBuffers when transaction is incomplete v2
Attachment #585656 - Attachment is obsolete: true
Attachment #585871 - Flags: review?(roc)
Attachment #585871 - Flags: review?(roc) → review+
(Assignee)

Comment 18

6 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/f1e771f3c2cd
Blocks: 579374
No longer depends on: 579374
Target Milestone: --- → mozilla12
https://hg.mozilla.org/mozilla-central/rev/f1e771f3c2cd
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.