Closed Bug 713572 Opened 8 years ago Closed 8 years ago

annoying black flicker on menus and dropdowns

Categories

(Core :: Graphics, defect)

x86_64
Linux
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla12

People

(Reporter: kdevel, Assigned: karlt)

References

Details

(Keywords: regression)

Attachments

(2 files, 1 obsolete file)

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+
OS: Other → Linux
Hardware: Other → x86_64
Summary: annoying flicker on tab content menu → annoying flicker on tab context menu
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?
Thanks very much for the regression window.
Which window manager is in use?  Is compositing enabled?
 (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.
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
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.
Attached file 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.
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?
Keywords: regression
Summary: annoying flicker on tab context menu → annoying black flicker on menus and dropdowns
(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?
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: nobody → karlt
Looks like we still need to BasicShadowableThebesLayer::PaintBuffer() even
with a null aCallback in order to process PaintState::mDidSelfCopy.
Attachment #585656 - Flags: review?(roc)
(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.
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)
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
Closed: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.