Closed Bug 713572 Opened 8 years ago Closed 8 years ago
annoying black flicker on menus and dropdowns
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 <firstname.lastname@example.org> 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
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.
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?
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!
Looks like we still need to BasicShadowableThebesLayer::PaintBuffer() even with a null aCallback in order to process PaintState::mDidSelfCopy.
(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 #585871 - Flags: review?(roc) → review+
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.