Bug 319184

Created attachment 79600 [details]
Example of invisible dropdown list, in Konqueror bug reporting page.

Looks like an update to the "nvidia black window" bug - please attach the output of "qdbus org.kde.kwin /KWin supportInformation"

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.

Created attachment 79601 [details]
KWin support information

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

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.

(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 ;-)

(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

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

Good catch, yes I can confirm that disabling Fade effect in Kwin makes drop down lists work fine again.

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

> 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.

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?

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

(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.

(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.