I tried that too (just for testing) and it didn't help. Now it was flickering all the time after alt-tabbing unti warcraft3 had the focus again.
Plus with wine as root there are some graphics glitches. In the warcraft3 menu there's for example the texture of the water missing.
I would like to edit my posts, but you know... So new post...
I had xfwm4 compositing on and with that it is impossible to get any window over a fullscreen 3d window. Without that compositing it works for "little" windows but the fullscreen window still flickers and sometimes hangs for a second when alt-tabbing. For "big" windows it still doesn't work.
Guys just use sdlhack to switch all SDL application
http://jspenguin.org:81/software/sdlhack/
and it is not a Linux's fault, just the developers do not want to bother with Linux Desktop's Usability.
remember some old Windows' games that had the same problems, such as Need For Speed 2
Interesting I know people who strip keys off their keyboard so they don't accidentaly switch out of their games on windows - just goes to show you can't please everyone.
Fullscreen for games gives you extra performance at the cost of a rather expensive context switch moving in and out of the application. I use the following trick for working with unigine it should work for other apps as well (in KDE at least). Set the geometry of the game window to be your native resolution set customise the window not to have a border - Ungine doesn't remember this setting (grrr). So in this case I have bound WIN+F11 to hide selected window border as a global shortcut. That way I get the window to behave as if it were a fullscreen window but still be running in windowed mode. This comes at a performance penalty but allows switching to code editors, 3d modellers etc.
Sorry for the age-old bump, but people told me to write in here incase I ever came across a solution, and I have.
Unfortunately, it requires hardware, although a hack may very well be possible. Please don't hesitate, code-gurus!
On my computer at least: Connect a second monitor and whoops, the problem goes away!
Sometimes it will work without doing this, but that appears to be a bug.
Apparently, if your virtual desktop is larger than the visible screenarea, the bug is resolved!
This is with FGLRX 10.8 all the way up to 11.2.
If I disconnect my second monitor, log out and back in again, and try to run the same program that was just working - it'll break.