Version: (using KDE 4.2.4) Compiler: gcc version 4.4.0 (GCC) OS: Linux Installed from: Compiled From Sources When a 3d game is launched in wine (specifically eve online) and desktop effects are turned on, the 3d video seems to not be confined into the bounds of its window but is drawn directly to the screen while simultaneously being redrawn by the contents of the windows beneath it (ie. flickering). Also for example when the desktop grid effect is used, all the desktops are zoomed out but the 3d video is still on the same place on the screen. The obvious cure to this is to disable the effects. But it also helps to disable and reenable them, as after that the 3d game is correctly bound to its window. Please fix this so that this step is not necessary. This seems to affect only wine, for example glxgears run fine. The graphics driver is fglrx 9.6. Xorg xserver-1.6.1. Architecture x86-64 (wine runs in a 32b chroot).
Driver/graphics architecture problem. As the 3D program is drawing directly to the screen framebuffer instead of the offscreen compositing window pixmaps there's nothing KWin can do about it.
I don't think this is the case, as I said: if effects are disabled and ENABLED again everything works normally.
What happens if you are using Compiz instead of KWin?
I don't have compiz. According to for example [1] the problem is solely with KDE and compiz works fine. If you insist though I might try to grab and test compiz in my spare time. [1] http://forum.winehq.org/viewtopic.php?t=5300&sid=9c5d3aea27b012607091b9401d962b30
Testing with Compiz is highly recommended. GNOME/Metacity compositing is done with XRender and not OpenGL like what KWin (By default) and Compiz use. I guess you can also test with XRender mode in KWin in System Settings -> Desktop -> Advanced to see if it's a compositing in general bug or something specific to OpenGL.
xrender mode does the same buggy behavior... i'll try to check with compiz too, just to verify i am getting the correct package http://xorg.freedesktop.org/releases/individual/app/compiz-0.7.8.tar.gz ?
I just checked with compiz and the bug happens there too, but is different. The window is displayed correctly when it is static and the flickering happens only when moving the window around, also when switching to a different desktop the window contents stops being drawn. So whose bug it is? And more importantly why is everything OK in KDE as long as you disable/enable effects while the app is running?
Problem is driver as it doesn't work correctly with Compiz as well. You can try to use the free Ati driver. The proprietary driver does not allow direct rendering for composition managers which is kind of broken.
(In reply to comment #8) > You can try to use the free Ati driver. I can't - no 3D. > The proprietary driver does not allow direct rendering for composition managers which is kind of broken. This explanation is kinda short handed, as I dont see how it explains the following: 1) glxgears does not have this problem but wine does 2) problem goes away when you disable and enable desktop effects while wine is running 3) problem reappears when you quit and launch wine again
just checked with nvidias dawn demo on a GT7600 (and lost 20 minutes steering there... =D ) there's no problem, so either there's a problem with your driver (it may check for the presence of a "compiz" process or compiz might have some win/ati workarounds), the specific wine app, your wine version, your wine settings or the bug is meanwhile fixed in kwin (though i think i steered there some time ago as well ;-) can you try other wine 3D apps (check what "Eve Online" uses, Direct3D or OpenGL, but try both if possible - any benchmark/demo should do) sidenote: i strongly suggest to suspend compositing when running unredirected 3D apps for performance reasons. usually i start my wine games through some scripts to adjust the environment (xrandr resizes, set some nvidia environments for fsaa/aniso, bend around symlinks to handle userpath save dirs, stuff) if you do similar: composited='qdbus org.kde.kwin /KWin compositingActive' if $composited; then qdbus org.kde.kwin /KWin toggleCompositing; fi wine blablabla if $composited; then qdbus org.kde.kwin /KWin toggleCompositing; fi
(In reply to comment #10) > just checked with nvidias dawn demo on a GT7600 (and lost 20 minutes steering > there... =D ) This demo segfaults in my wine ... > there's no problem, so either there's a problem with your driver (it may check > for the presence of a "compiz" process or compiz might have some win/ati > workarounds), the specific wine app, your wine version, your wine settings or > the bug is meanwhile fixed in kwin (though i think i steered there some time > ago as well ;-) I tried to run a fake compiz process, to no avail. I'm not sure if you noticed in a previous post that compiz has this bug too albeit in a different manner. Furthermore in kwin the bug manifests both when xrener and gl are used for effects. My kwin version is 4.2.4. > can you try other wine 3D apps (check what "Eve Online" uses, Direct3D or > OpenGL, but try both if possible - any benchmark/demo should do) Eve uses DX afaik. I have used my own OpenGL program from this address: http://spatium.org/gsy/2 and wonders, it suffers from the same problem, and again, disabling and enabling effects while the program is running fixes it. The native linux version of the program does NOT have this problem. I would happily bother wine folks with this but the presence of the workaround gives me enough evidence that this is connected to kwin as well. > i strongly suggest to suspend compositing when running unredirected 3D apps for performance reasons. I suffer no noticeable performance penalty with compositing so far. Thanks for the dbus tip though.
I do not really understand why you reopened the bug. Given the comments it's quite obvious that you are using a buggy driver. Especially your description in comment #9 states that it is a buggy driver. The driver is unable to process OpenGL apps correctly when compositing is running, but is able to process compositing correclty when an OpenGL app is already running. Unfortunately I do not have any wine apps around to test. So another 3D app from KDE games for testing would be Kubrik which works perfectly fine with my NVIDIA.
apparently the bug /only/ occurs with wine apps (so testing kubrik won't help), but as mentioned the bug seems to be either in wine, ati/amd or is meanwhile fixed in kwin (i assume overlay gets disabled when the redirection is initiated, but the redirection state is not taken into account when the overlay context is initiated) @michael: no dawn for ati jerks ;-P (even on windows you'd afaik need some patches and even patched drivers to make it run) ati should however provide some demos as well (look for "ruby")
Martin, I reopened the bug because it seemed that you dismissed the bug without any deeper explanation. Now you've given at least some. Let me retest with kde 4.3 when it comes out and/or with nvidia drivers.
I reported an enhancement bug on wine's bugtracker to implement support for suspending compositing (http://bugs.winehq.org/show_bug.cgi?id=19376)
Well that was quick - the feature request has been closed: > If a user wishes to disable 3d compositing with a shell script, there's nothing stopping them from doing so. Wine, however, has no business doing this for users. Well given that I will probably not consider bothering about wine bugs with kwin any more :-(
hehe - i was about to tell you that would fail... but there's an update from someone who knows that the D3D api knows such function =D however: as we should be more interested in users experience than in wine (and this isn't a wine only issue), i'd suggest to extend the kwin dbus interface by blockCompositing Bool internally there would be a counter - true increases it, false decreases it if (it's > 0) { compositing remains suspended } while blocked, other calls to (un)suspend it are ignored - or maybe scheduled (the problem here however would that the user may loose any idea about the demanded compositing state in latter case) the next step was to add composition to kwins already mighty & powerful rule system (workarounds) - making use of the same function =)
*** Bug 211407 has been marked as a duplicate of this bug. ***
*** Bug 238749 has been marked as a duplicate of this bug. ***
*** Bug 247314 has been marked as a duplicate of this bug. ***
I am experiencing wine problems with desktop effects disabled (yeah disabled!) Running wine and railroad tycoon 3 on windowed mode (wine virtual desktop) and then switch desktop produce different results with /without desktop effects. Desktop effects disabled: running the game, then switching desktop and switch desktop again and the window wine game is totally white no image, sometimes you need a few times to trigger this bug but it always appears after a few time of switching desktop. Desktop effects enabled: All is working fine.
I am using ubuntu maverick, default kde 4.5.1 and default radeon open source drivers.
@Daniel: different bug - likely the game / wine has issues on minimzation (check your advanced compositing settings, is "keep window thumbnails" set to always? could also be for indirect rendering) However, this is completely kwin unrelated, if unmapping breaks a client, the client is broken (report to wine or the rrt3 devs)
*** Bug 170293 has been marked as a duplicate of this bug. ***
kwin rules meanwhile allow to block compositing for certain windows (ie. as long as they are there the compositor is turned off, similar to what MS aero does) Since the described behavior is very likely a (known) fglrx bug (happens mostly with xv), the variances between compiz & kwin are clipping related (which has seen several updates in kwin as well) and suspending the compositor for certain clients is all we can really do ("works if you suspend and resume" clearly points an ATI/Wine bug failing on the display depth when aligning to the overlay color and a rule to suspend and resume n seconds afterwards is not in the cards - far too complex for far to much corner case issue) this one "works for me", bug ati to fix fglrx or use the radeon driver instead.