Closed
Bug 713572
Opened 13 years ago
Closed 13 years ago
annoying black flicker on menus and dropdowns
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
FIXED
mozilla12
People
(Reporter: kdevel, Assigned: karlt)
References
Details
(Keywords: regression)
Attachments
(2 files, 1 obsolete file)
4.20 KB,
text/plain
|
Details | |
2.07 KB,
patch
|
roc
:
review+
|
Details | Diff | Splinter Review |
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
Updated•13 years ago
|
Component: General → Widget: Gtk
Product: Firefox → Core
QA Contact: general → gtk
Comment 1•13 years ago
|
||
Maybe we should be doing ClearCachedResources at the end of nsWindow::Show?
Comment 2•13 years ago
|
||
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•13 years ago
|
||
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.
Assignee | ||
Comment 5•13 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
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•13 years ago
|
||
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•13 years ago
|
Component: Widget: Gtk → Graphics
QA Contact: gtk → thebes
Comment 8•13 years ago
|
||
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•13 years ago
|
Keywords: regression
Summary: annoying flicker on tab context menu → annoying black flicker on menus and dropdowns
Assignee | ||
Comment 9•13 years ago
|
||
(In reply to Timothy Nikkel (:tn) from comment #8) It has been shown again.
Comment 10•13 years ago
|
||
Ah, ok. So it must be an invalidate after drawing the black and then it draws correctly? When does that happen?
Assignee | ||
Comment 11•13 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•13 years ago
|
Assignee: nobody → karlt
Assignee | ||
Comment 13•13 years ago
|
||
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•13 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•13 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•13 years ago
|
||
Attachment #585656 -
Attachment is obsolete: true
Attachment #585871 -
Flags: review?(roc)
Attachment #585871 -
Flags: review?(roc) → review+
Assignee | ||
Comment 18•13 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/f1e771f3c2cd
Comment 19•13 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/f1e771f3c2cd
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•