I have noticed that the accuracy of the KDE4 desktop effects depends on current state of other opened application - for example in a youtube clip is running in a browser the expose function respond sluggish , after quitting the browser page makes the expose respond again quickly. I don't know how the compiz are solved that dependency but it seems compiz perfornance hasn't been affected of performance of other running applications. If it is a question of settings what I am supposed to do in KDE4 settings ?
Speaking of compiz is that a way to use it with KDE4 - 4.8 ? It sometimes manage to work but do not move windows and do not draws windows bars. It seems something has been changed since KDE4 4.6 and compiz 0.8 - 0.9 does not fit it anymore.
----
OpenSuSE 12.1 x 64 Nvidia drivers 295.xxx GeForce 8300 KDE 4.8.4

re: compiz from http://en.opensuse.org/Compiz_Fusion

.....but KDE 4.6 reportedly breaks Compiz. There is no good solution. You can try the 11.3 instructions, and you might be lucky enough to get it to start, but it will crash immediately

. You can search openSUSE's forums as there are various threads regarding this, iirc there's the suggestion that you install an older version of compiz and it may work.

You can try the html5 version of youtube to see if it helps with cpu utilization http://www.youtube.com/html5

The standard compiz is 0.9xx with OpenSuSE 12.1 and does not work properly neither with KDE4 nor Gnome 3.2 ... anyway if that is an issue with OpenSuSE my asking was if KDE 4.8 and coming 4.9 could use compiz as a composite manager the same manner they use kwin and the second asking if there is a way one to set desktop effect in KDE4 to be less depending on other running applications as compiz does. My example with youtube was just an example, kwin responds sluggish if any app happens to use lots of CPU or RAM even my ram is 8 GB. In the same situation compiz manages to work as there no other apps running.

Compiz developers are no longer interested in supporting anything except Unity. Based on that the KWin developers do not consider Compiz any more when doing changes. It is extremely unlikely that Compiz works together with 4.9.

Switching the Compositor is also no solution to solve a problem So let's try to solve your problem. In case you are using 4.9 (which I would highly recommend to use), please post the output of:
qdbus org.kde.kwin /KWin supportInformation

Thanks answering me. Well I switched to KDE 4.9 a few days ago. Here is the output as you asked :
two@white:~/Documents> qdbus org.kde.kwin /KWin supportInformation
KWin Support Information:
The following information should be used when requesting support on e.g. http://forum.kde.org.
It provides information about the currently running instance, which options are used,
what OpenGL driver and which effects are running.
Please post the information provided underneath this introductory text to a paste bin service
like http://paste.kde.org instead of pasting into support threads.

==========================

Options
=======
focusPolicy: 0
nextFocusPrefersMouse: false
clickRaise: true
autoRaise: false
autoRaiseInterval: 0
delayFocusInterval: 0
shadeHover: false
shadeHoverInterval: 250
tiling: false
tilingLayout: 0
tilingRaisePolicy: 0
separateScreenFocus: false
activeMouseScreen: false
placement: 6
focusPolicyIsReasonable: true
borderSnapZone: 10
windowSnapZone: 10
centerSnapZone: 0
snapOnlyWhenOverlapping: false
showDesktopIsMinimizeAll: false
rollOverDesktops: true
focusStealingPreventionLevel: 1
legacyFullscreenSupport: false
operationTitlebarDblClick:
commandActiveTitlebar1: 0
commandActiveTitlebar2: 30
commandActiveTitlebar3: 2
commandInactiveTitlebar1: 4
commandInactiveTitlebar2: 30
commandInactiveTitlebar3: 2
commandWindow1: 7
commandWindow2: 8
commandWindow3: 8
commandWindowWheel: 31
commandAll1: 10
commandAll2: 3
commandAll3: 14
keyCmdAllModKey: 16777251
showGeometryTip: false
electricBorders: false
electricBorderDelay: 50
electricBorderCooldown: 350
electricBorderPushbackPixels: 1
electricBorderMaximize: true
electricBorderTiling: true
borderlessMaximizedWindows: false
killPingTimeout: 5000
hideUtilityWindowsForInactive: true
inactiveTabsSkipTaskbar: false
autogroupSimilarWindows: false
autogroupInForeground: true
compositingMode: 1
useCompositing: true
compositingInitialized: true
hiddenPreviews: 1
unredirectFullscreen: false
glSmoothScale: 2
glVSync: true
xrenderSmoothScale: false
maxFpsInterval: 17
refreshRate: 0
vBlankTime: 6144
glDirect: true
glStrictBinding: false
glStrictBindingFollowsDriver: true

Compositing
===========
Qt Graphics System: raster
Compositing is active
Compositing Type: OpenGL
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce 8300/integrated/SSE2
OpenGL version string: 3.3.0 NVIDIA 295.71
Driver: NVIDIA
Driver version: 295.71
GPU class: G80/G90
OpenGL version: 3.3
X server version: 1.10.4
Linux kernel version: 3.1.10
Direct rendering: yes
Requires strict binding: no
GLSL shaders: yes
Texture NPOT support: yes
OpenGL 2 Shaders are used

Loaded Effects:
---------------
kwin4_effect_thumbnailaside
kwin4_effect_zoom
kwin4_effect_login
kwin4_effect_slidingpopups
kwin4_effect_wobblywindows
kwin4_effect_fadedesktop
kwin4_effect_coverswitch
kwin4_effect_slideback
kwin4_effect_scalein
kwin4_effect_translucency
kwin4_effect_minimizeanimation
kwin4_effect_desktopgrid
kwin4_effect_flipswitch
kwin4_effect_taskbarthumbnail
kwin4_effect_highlightwindow
kwin4_effect_presentwindows
kwin4_effect_blur
kwin4_effect_dashboard
kwin4_effect_logout
kwin4_effect_startupfeedback
kwin4_effect_outline

Currently Active Effects:
-------------------------
kwin4_effect_translucency
kwin4_effect_blur

two@white:~/Documents>
My observations up to now are that kwin uses significatly less CPU power playnig video files then it was with previous KDE4 versions - an unexpectant and pleasant surprice.

ok, given this I think the best way is to change the thumbnail scaling algorithm, this should have the highest influence on the performance in the Present Windows effect. Please follow the instructions on Userbase (Desktop Effects Performance)

mgraesslin wrote:ok, given this I think the best way is to change the thumbnail scaling algorithm, this should have the highest influence on the performance in the Present Windows effect. Please follow the instructions on Userbase (Desktop Effects Performance)

I don't think, this will help. KWin is slow if any other app uses GPU (eg. xbmc (even idle), mplayer with vdpau vc, flashplugin with accelerated rendering or/and decoding). Here's example with mplayer (software vs hardware decoding) http://youtu.be/7VtHz4RNfac

smells like double syncing.
Please deactivate vsync in kwin and check the outcome.
Next post your nvidia-settings settings in that regard (gl and video syncing)

luebking wrote:smells like double syncing.

Indeed, SyncToVBlank is on by default now in nvidia binary driver, but I didn't known this settings can stack. Anyway, switching vsync off in kwin ending with tearing; in nvidia-setting doesn't make any difference. Full nvidia settings query: http://pastebin.com/D3qyEuaR

so (most important info) you get back 60fps when turning off vsync in kwin and play a vdpau video?

you're aware that the nvidia-settings value only impacts applicatins stated after the change?
also please check the xvideo syncing settings.

just remembering: Fredrik's change concerning the grabServer in the SceneOpenGL mentioned vdpau. Maybe we should backport that one to 4.9.2?

luebking wrote:so (most important info) you get back 60fps when turning off vsync in kwin and play a vdpau video?

Close (about~58fps), but kwin (moving windows, efects animations) remains choppy during playback.

luebking wrote:you're aware that the nvidia-settings value only impacts applicatins stated after the change?

Yes, I'm. I've autostarted nvidia settings and confirmed by quering nividia-settings.

luebking wrote:also please check the xvideo syncing settings.

mgraesslin wrote:just remembering: Fredrik's change concerning the grabServer in the SceneOpenGL mentioned vdpau. Maybe we should backport that one to 4.9.2?

Yes, that's great
https://projects.kde.org/projects/kde/k ... c5d08401a5

... but it's not only video. It can be very simple OpenGL game (vsyced, windowed @ 640x480, just to be sure it not stessing GTX 570 too much or apps like mentioned xbmc (idling at menu) - same effect.

- does it also happen with an unsynced OpenGL "game" (ie. glxgears)
- the nvidia-settings dump suggests you're in performance mode, nevertheless, what happens if you enforce the performance mode (ie. full clock rates)

luebking wrote:- does it also happen with an unsynced OpenGL "game" (ie. glxgears)

Thanks, that's it. Now, KWin is smooth. Sorry, I haven't tested games with vsync off earlier. But that's workaround, beside benchmarking we don't want unsynced *anything*. What else can be done?

luebking wrote:- the nvidia-settings dump suggests you're in performance mode, nevertheless, what happens if you enforce the performance mode (ie. full clock rates)

Powermizer works fine (or "too fine", entering max performance too aggressive), enforcing max performance doesn't change anything.

But that's workaround, beside benchmarking we don't want unsynced *anything*

Yes, you do.
As long as there's compositing, you're effectively indirect rendering (the compositor textures don't have a vertical retrace or so to wait for)

Applications render into the texture and and compositor syncs the result to the vertical retrace on the screen, ie. kwin syncing is about the only one to be activated (the situation becomes worse because the applications will likely utilize glXSwapInterval which only applies to glXSwapBuffers while kwin uses glWaitVideoSyncSGI because most of the time it does not swap buffers since that would mean to constantly repaint the entire screen what kills weaker GPUs)

Otherwise you'll inevitably get double syncing and by this half the FPS (of your Screen, ie 30FPS instead of 60!)

The problem here becomes the sloppy texure_from_pixmap binding which can cause the offscreen texture to be partially changed when mapped to the frontbuffer and _before_ the according damage event, but that *cannot* be fixed by syncing the client as well, but if, then by the sync fences (for nvidia)

Actually syncing one context (glxgears) should not block the other (kwin) or rather syncing glxgears while compositing is active should not be possible at all.

Long term solution is clearly to get away from the current X -> GL -> compositing graphics stack.