Bug 319184 - Dropdown lists appear invisible
Summary: Dropdown lists appear invisible
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: compositing (show other bugs)
Version: 4.10.2
Platform: Ubuntu Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: KWin default assignee
URL: https://git.reviewboard.kde.org/r/111...
Keywords:
Depends on:
Blocks:
 
Reported: 2013-05-01 17:27 UTC by Michael Reiher
Modified: 2013-07-03 20:47 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 4.11
thomas.luebking: ReviewRequest+


Attachments
Example of invisible dropdown list, in Konqueror bug reporting page. (66.93 KB, image/png)
2013-05-01 17:29 UTC, Michael Reiher
Details
KWin support information (4.84 KB, text/plain)
2013-05-01 17:41 UTC, Michael Reiher
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Reiher 2013-05-01 17:27:44 UTC
With compositing enabled I get entirely transparent or invisible dropdown lists. As you can see in the screenshot the shadows around it are drawn, but the content is invisible (what you can see is actually behind the dropdown). All other popup menus and such appear just fine.

When I open the list 3 times or so I eventually get to see it correctly.

This problem was not always there, it appeared at some point quite a while ago. Unfortunately I can not say exactly when and what I did. But as far as I remember it appeared after a KDE upgrade. Although I can not exclude that there were other relevant updates as well.

Graphics chip: Nvidia Geforce 320M.
Driver: Nvidia binary blob 304.88-0ubuntu0.0.2
Xserver: 1.11.4-0ubuntu10.13 


Reproducible: Always
Comment 1 Michael Reiher 2013-05-01 17:29:55 UTC
Created attachment 79600 [details]
Example of invisible dropdown list, in Konqueror bug reporting page.
Comment 2 Thomas Lübking 2013-05-01 17:32:38 UTC
Looks like an update to the "nvidia black window" bug - please attach the output of "qdbus org.kde.kwin /KWin supportInformation"
Comment 3 Michael Reiher 2013-05-01 17:38:58 UTC
I forgot to say that this seems to happen only with dropdown lists in webpages within Konqueror/KHTML. Not in "normal" widgets, not in rekonq or Firefox. But as it seems compositing related I thought kwin is a good place to report.
Comment 4 Michael Reiher 2013-05-01 17:41:13 UTC
Created attachment 79601 [details]
KWin support information
Comment 5 Thomas Lübking 2013-05-01 17:59:58 UTC
1. So it's not "black" w/o compositing?
2. Does it happen w/o the blur effect?
3. Does it happen with another GUI style (eg. CDE or Plastique but NOT oxygen, bespin, QtCurve)?
4. Does it happen with XRender compositing?
5. does it happen with either
  5a) konqueror --graphicssystem raster
  5b) konqueror --graphicssystem native
Comment 6 Michael Reiher 2013-05-05 16:09:37 UTC
One more observation I just made is that the dropdown list content shows up very briefly before becoming invisible. Could this be during the fade in animation?

(In reply to comment #5)
> 1. So it's not "black" w/o compositing?
No, without compositing everything is fine.

> 2. Does it happen w/o the blur effect?
Does not seem to have any influence.

> 3. Does it happen with another GUI style (eg. CDE or Plastique but NOT
> oxygen, bespin, QtCurve)?
Tried with Plastique and it happens there as well. No difference on running processes after switching. Though on newly started konquerors dropdowns appear now black instead of transparent.

> 4. Does it happen with XRender compositing?
Seems indeed fine with XRender compositing.

> 5. does it happen with either
>   5a) konqueror --graphicssystem raster
>   5b) konqueror --graphicssystem native
Does not seem to have any influence.
Comment 7 Thomas Lübking 2013-05-05 16:42:58 UTC
(In reply to comment #6)
> One more observation I just made is that the dropdown list content shows up
> very briefly before becoming invisible. Could this be during the fade in
> animation?

Theoretically, but only indirectly (because of the XRender situation
But since it
1. happens with GL only
2. is black for RGB and transparent for ARGB windows (ie. invalid GL texture)
it smells a lot like the known "black window" bug - if you activate 1212 in kdebugdialog you'll likely get some GL errors about invalid textures (see bug #283202 - or just google)

But the restriction to konqueror comboboxes is rather uncommon - as well as that you can briefly see it.

a) In qtconfig[-qt4] do you have any "Gui Effects" enabled ("Interface" tab, in particular a  Combobox effect, of course)?
b) kwriteconfig --file kwinrc --group Compositing --key GLStrictBinding true
   then "kwin --replace&"

If that does not help you should better delete the key from the ini (kwrite - or use a better kconfig tool: https://git.reviewboard.kde.org/r/109892/ /avert ;-)
Comment 8 Michael Reiher 2013-05-05 17:33:13 UTC
(In reply to comment #7)
> 2. is black for RGB and transparent for ARGB windows (ie. invalid GL texture)
> it smells a lot like the known "black window" bug - if you activate 1212 in
> kdebugdialog you'll likely get some GL errors about invalid textures (see
> bug #283202 - or just google)

When opening a dropdown it says:

kwin(7547) KWin::Toplevel::createWindowPixmap: Creating window pixmap failed:  'ID: 138412377 ' (deleted)

> 
> But the restriction to konqueror comboboxes is rather uncommon - as well as
> that you can briefly see it.
Does konqueror/KHTML perhaps do some custom rendering of UI elements which is different from the usual UI rendering?

> a) In qtconfig[-qt4] do you have any "Gui Effects" enabled ("Interface" tab,
> in particular a  Combobox effect, of course)?
No GUI Effects are enabled.

> b) kwriteconfig --file kwinrc --group Compositing --key GLStrictBinding true
>    then "kwin --replace&"
Didn't make any difference.

$ qdbus org.kde.kwin /KWin supportInformation|grep -i strict
glStrictBinding: true
glStrictBindingFollowsDriver: false
Requires strict binding: no
Comment 9 Attila 2013-05-20 14:04:35 UTC
I can confirm this bug running konqueror with KHTML.
When I disable the fade effect, the dropdown list is always OK. After activating the fade effect again, the content of the dropdown list is invisible.
I can reproduce this behavior always.
Graphics chip: GeForce FX 5200 + several different NVidia chips
Comment 10 Michael Reiher 2013-05-25 12:44:43 UTC
Good catch, yes I can confirm that disabling Fade effect in Kwin makes drop down lists work fine again.
Comment 11 Thomas Lübking 2013-06-27 20:56:02 UTC
can reproduce now as well.

not related to blurring (though the window is ARGB), color correction or strict binding.
happens with several styles.
happens with generic animations as well.

happens ~4/5 times.
was unable to ever reproduce it with xrender.

occasionally alongside error 8 on WindowPixmap::create() and for namePixmapCookie (yes, xcb error 8 - not some ebkac ;-)

did NOT get errors on server grabbing attempts
Comment 12 Martin Flöser 2013-06-28 05:40:43 UTC
> occasionally alongside error 8 on WindowPixmap::create() and for
> namePixmapCookie (yes, xcb error 8 - not some ebkac ;-)
I'm regularly seeing these errors. Error code 8 is a Match error. But I have 
never seen that the window isn't shown.
Comment 13 Thomas Lübking 2013-06-28 12:48:39 UTC
The window "flickers" - it maps/unmaps/maps in one event cycle.
I've no idea why this affects texture generation + animated adding (and apparently mostly nvidia related - i guess it's related to the known nvidia issue and due to magics of re-using stuff or whatever) but it's a good reason to delay adding unmanged windows (by 50ms) what also coveres "i map and the update" flicker, ie. gets us a synthetic XSYNC protocol here.

@Michael or Attila - can you try:
https://git.reviewboard.kde.org/r/111292/
to confirm my observations?
Comment 14 Thomas Lübking 2013-07-01 19:28:00 UTC
Git commit b9b4b918c2f241d81a95f87a37414ccc62b233b8 by Thomas Lübking.
Committed on 28/06/2013 at 12:23.
Pushed by luebking into branch 'master'.

delay adding Unmanaged clients by 50ms

This provides some sort of synthetic XSYNC support
for unmanaged clients and allows them to do an initial
update after mapping and before being painted (prevent
flicker)
Also it helps with Unmanaged clients performing quick
map/unmap/map cycles what also seems to induce the black
window issue on the nvidia blob.
Related: bug 284888
FIXED-IN: 4.11
REVIEW: 111292

M  +11   -3    kwin/effects.cpp
M  +1    -0    kwin/effects.h
M  +1    -1    kwin/toplevel.h
M  +3    -0    kwin/unmanaged.cpp

http://commits.kde.org/kde-workspace/b9b4b918c2f241d81a95f87a37414ccc62b233b8
Comment 15 Attila 2013-07-03 20:31:15 UTC
(In reply to comment #13)
> The window "flickers" - it maps/unmaps/maps in one event cycle.
> I've no idea why this affects texture generation + animated adding (and
> apparently mostly nvidia related - i guess it's related to the known nvidia
> issue and due to magics of re-using stuff or whatever) but it's a good
> reason to delay adding unmanged windows (by 50ms) what also coveres "i map
> and the update" flicker, ie. gets us a synthetic XSYNC protocol here.
> 
> @Michael or Attila - can you try:
> https://git.reviewboard.kde.org/r/111292/
> to confirm my observations?

Sorry, I would like to confirm your patch but I get an error during the compilation of kde-workspace-4.10.4 (Fedora 18, the latest KDE rpm by Fedora is 4.10.4).

Snippet of error:
kde-workspace-4.10.4/kwin/client.cpp: In Elementfunktion »void KWin::Client::removeSyncSupport()
kde-workspace-4.10.4/kwin/client.cpp:2220:29: Fehler: »setReadyForPainting« wurde in diesem Gültigkeitsbereich nicht definiert

I guess, I have to wait for KDE 4.11 to confirm. Anyway - Thank you for the patch.
Comment 16 Thomas Lübking 2013-07-03 20:47:27 UTC
(In reply to comment #15)

> Snippet of error:
> kde-workspace-4.10.4/kwin/client.cpp: In Elementfunktion »void
> KWin::Client::removeSyncSupport()
> kde-workspace-4.10.4/kwin/client.cpp:2220:29: Fehler: »setReadyForPainting«
> wurde in diesem Gültigkeitsbereich nicht definiert


That sounds as if the patch failed (you got some hunk message) as the function itself is present and preotected in toplevel.h of 4.10.4 and just moved over to Q_SLOTS for the patch.