Created attachment 64840 [details]
screen shot showing that behavior

There's no popup dialog but a popup menu in that screenshot, assuming you were referring to those in general (ie. it's a shadow - menucontent issue)

a) how long (appr.) is the lag time?
b) try "kwrite --graphicssystem raster" as well as "kwrite --graphicssystem native" - does it happen with either?
c) does it happen with both compositor backends (OpenGL/XRender, see "kcmshell4 kwincompositing", 3rd tab) - try both (b) cases with either backend and report, thanks.

Hi Christoph,

Thanks for your fast reply.

(In reply to comment #2)
> There's no popup dialog but a popup menu in that screenshot, assuming you were
> referring to those in general (ie. it's a shadow - menucontent issue)

Your assumption is correct → this shadow - menucontent issue is what mean.


> a) how long (appr.) is the lag time?

Hard to say in general. If there is a lot of I/O load going on — like now (migrating KMails :P), it can take even seconds. In many cases it is hardly perceivable, in some cases it looks like flickering. This effect gets stronger when enabling the blur effect (which I disabled for that reason).

> b) try "kwrite --graphicssystem raster" as well as "kwrite --graphicssystem
> native" - does it happen with either?

I am running raster by default, but it happens with native rendering, as well. 


> c) does it happen with both compositor backends (OpenGL/XRender, see "kcmshell4
> kwincompositing", 3rd tab) - try both (b) cases with either backend and report,
> thanks.

By default, I am using OpenGL, but it also happens with XRender.

In the case of menus, often Qt needs to load the menu icons before showing them, so the initial sync() will be delayed. KWin should wait for the sync() before starting compositing it.

At least that should be fixed in 4.8 - https://git.reviewboard.kde.org/r/102311/

Well, in case of menus, I see a black area appearing shortly before the content. I blame the intel drivers for this bug, though.

(In reply to comment #6)
> Well, in case of menus, I see a black area appearing shortly before the
> content.
With Skulpture?? Do you use ARGB popups?

> I blame the intel drivers for this bug, though.
In case it's an ARGB popup, the intel driver is responsible for the "black" of what should be "transparent", but in general it the very same issue.

This would mean that
a) the sync timer times out (we don't wait ages for the window to get itself ready _after_ the maprequest) or
b) QMenu doesn't support netwm_sync at all

Skulpture (still) does not use any ARGB stuff, it simply paints on the given painters. Looking at b), I wonder what an application has to do to "support" netwm_sync. I mean, I always thought that calling XFlush() or XSync() (or whatever Qt uses at the begin/end of the event loop) is enough to signal that it is finished drawing.

Looking at the NETWM specs, it looks like it is only used to synchronize rendering between two X Windows (the decoration, and the client).

In case of the popup menu, there is only a single X Window (and before you ask: Skulpture does not yet support popup shadows ;)

I do not see the issue with Oxygen, but it is visible with e.g. Plastique, too.

No, XSync(false) is NOT the same as the XSync extension (don't ask me who picked the name)
The XSync extension is defined in extensions/sync[proto|const|str].h and describes some sort of inter-client mutex system.

The NETWM usage is "specified" here:
http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2552503

It's used to sync client and decoration, but kwin (just as assumingly compiz) also sends (and now honors) an initial syncRequest, but errrrmmm... as i just realize: to MANAGED clients, what popups are not :S

We'd have to check whether we can do this with unmanged clients as well.

(In reply to comment #6)
> I blame the intel drivers for this bug, though.

BTW: I am using intel.

(In reply to comment #11)
> (In reply to comment #6)
> > I blame the intel drivers for this bug, though.
> 
> BTW: I am using intel.


> micu@denkbrett:~$ kwin
> QDBusConnection: session D-Bus connection created before
> QCoreApplication. Application may misbehave. OpenGL vendor string: 
>                  Tungsten Graphics, Inc OpenGL renderer string:    
>             Mesa DRI Intel(R) 965GM OpenGL version string:         
>         2.1 Mesa 7.11
> OpenGL shading language version string: 1.20
> Driver:                                 Intel
> GPU class:                              i965
> OpenGL version:                         2.1
> GLSL version:                           1.20
> Mesa version:                           7.11
> Linux kernel version:                   3.1.1
> Direct rendering:                       yes
> Requires strict binding:                yes
> GLSL shaders:                           yes
> Texture NPOT support:                   yes

is this still an issue with a later version of KDE SC (e.g. 4.9 or 4.10)?

(In reply to comment #13)
> is this still an issue with a later version of KDE SC (e.g. 4.9 or 4.10)?

Yes, unfortunately, I am still experiencing this behaviour with KDE 4.9.5

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

did you have the chance to re-test with 4.11? Did the patch from comment #15 improve the situation?

Assuming fixed given that there was no complain after a year.