would you mind providing some relevant data like the output of
qdbus org.kde.kwin /KWin supportInformation
;-)

if just a mesa ungrade got you trouble, this is however likely a mesa or configuration issue (like you're suddenly running on llvmpipe or so)

(In reply to comment #1)
> (like you're suddenly running on llvmpipe or so)
which is quite likely as the code in 4.9 IIRC would happily accept running on llvmpipe for GLES.

(In reply to comment #1)
> would you mind providing some relevant data like the output of
> qdbus org.kde.kwin /KWin supportInformation
> ;-)
> 
> if just a mesa ungrade got you trouble, this is however likely a mesa or
> configuration issue (like you're suddenly running on llvmpipe or so)

Options
=======
focusPolicy: 0
nextFocusPrefersMouse: false
clickRaise: true
autoRaise: false
autoRaiseInterval: 0
delayFocusInterval: 0
shadeHover: false
shadeHoverInterval: 250
tiling: false
tilingLayout: 1
tilingRaisePolicy: 0
separateScreenFocus: false
activeMouseScreen: false
placement: 4
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: true
electricBorderDelay: 0
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: true
glSmoothScale: 2
glVSync: true
xrenderSmoothScale: false
maxFpsInterval: 17
refreshRate: 0
vBlankTime: 6144
glDirect: true
glStrictBinding: true
glStrictBindingFollowsDriver: true

Compositing
===========
Qt Graphics System: native
Compositing is active
Compositing Type: OpenGL ES 2.0
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Mobile 
OpenGL version string: OpenGL ES 2.0 Mesa 9.0
Driver: Intel
GPU class: SandyBridge
OpenGL version: 2.0
Mesa version: 9.0
X server version: 1.13
Linux kernel version: 3.5.6
Direct rendering: yes
Requires strict binding: no
GLSL shaders:  yes
Texture NPOT support:  yes
OpenGL 2 Shaders are used

Loaded Effects:
---------------
kwin4_effect_zoom
kwin4_effect_login
kwin4_effect_slidingpopups
kwin4_effect_minimizeanimation
kwin4_effect_translucency
kwin4_effect_screenshot
kwin4_effect_slide
kwin4_effect_slideback
kwin4_effect_desktopgrid
kwin4_effect_fade
kwin4_effect_dialogparent
kwin4_effect_highlightwindow
kwin4_effect_taskbarthumbnail
kwin4_effect_presentwindows
kwin4_effect_blur
kwin4_effect_logout
kwin4_effect_dashboard
kwin4_effect_outline
kwin4_effect_startupfeedback

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

Effect Settings:
----------------
kwin4_effect_zoom:
zoomFactor: 1.25
mousePointer: 0
mouseTracking: 0
enableFocusTracking: false
followFocus: true
focusDelay: 350
moveFactor: 20
targetZoom: 1

kwin4_effect_login:
fadeToBlack: false

kwin4_effect_slidingpopups:
fadeInTime: 250
fadeOutTime: 250

kwin4_effect_minimizeanimation:

kwin4_effect_translucency:
decoration: 1
moveResize: 0.8
dialogs: 1
inactive: 1
comboboxPopups: 1
menus: 1
individualMenuConfig: false
dropDownMenus: 1
popupMenus: 1
tornOffMenus: 1

kwin4_effect_screenshot:

kwin4_effect_slide:

kwin4_effect_slideback:

kwin4_effect_desktopgrid:
zoomDuration: 300
border: 10
desktopNameAlignment: 0
layoutMode: 2
customLayoutRows: 2
usePresentWindows: true

kwin4_effect_fade:

kwin4_effect_dialogparent:
changeTime: 300

kwin4_effect_highlightwindow:

kwin4_effect_taskbarthumbnail:

kwin4_effect_presentwindows:
layoutMode: 0
showCaptions: true
showIcons: true
doNotCloseWindows: false
ignoreMinimized: false
accuracy: 20
fillGaps: true
fadeDuration: 150
showPanel: false
leftButtonWindow: 1
rightButtonWindow: 2
middleButtonWindow: 0
leftButtonDesktop: 2
middleButtonDesktop: 0
rightButtonDesktop: 0
dragToClose: false

kwin4_effect_blur:
blurRadius: 12
cacheTexture: true

kwin4_effect_logout:
useBlur: true

kwin4_effect_dashboard:
brightness: 0.5
saturation: 0.5
blur: false

kwin4_effect_outline:

kwin4_effect_startupfeedback:

Try to disable the blur effect, if that helps, lower the blur radius.
If at a certain point there's a significant performace boost, that's it.

(I think GLES just guesses the capabilities, does it?)

(In reply to comment #4)
> Try to disable the blur effect, if that helps, lower the blur radius.
> If at a certain point there's a significant performace boost, that's it.
> 
> (I think GLES just guesses the capabilities, does it?)

No, the problem it isn't the blur.

(In reply to comment #4)
> (I think GLES just guesses the capabilities, does it?)
for SandyBridge it should not make any difference at all.

Does the problem go away when switching from GLES to normal GL? The EGL backend is not yet as good as the GLX one, e.g. doesn't provide vsync.

(In reply to comment #6)
> (In reply to comment #4)
> > (I think GLES just guesses the capabilities, does it?)
> for SandyBridge it should not make any difference at all.
> 
> Does the problem go away when switching from GLES to normal GL? The EGL
> backend is not yet as good as the GLX one, e.g. doesn't provide vsync.

Yes, all normal with the GL.

I use kwin with just gl and not gles, and I experience some performance issues with new mesa 9.0. But it's just a performance issues without any glitches and so. I think that's a vsync issue. Downgrading to mesa 8.0.4 fixes that.

Lenovo X220, Intel HD3000, KDE 4.9.2, ArchLinux.

(In reply to comment #8)
> I think that's a vsync issue.
Double sync? (you'd get 30FPS with the show fps plugin)

http://www.youtube.com/watch?v=o7Elvm1FMNw
FPS drops down to 45-50 fps even without vsync. BTW no fps drop when recording in recordmydesktop.

No double sync then, might be related to relaxed feature limitations (check the impact of blurring and "accurate" scaling) then - also rather don't use OpenGL 2 shaders with GMA < 965, the FFP performs better (at least did so here)

Also check your Xorg log whether you might have dropped from SNA to UXA or so.

It doesn't matter SNA or UXA, it lags on both.
With 8.0.4 I get 60 constant fps. Will update and reboot again now.

Well, yes, I get 60 fps with blur disabled. But I desync lower than with mesa 8.0.4. I mean, on intel 3000 with RC6 enabled you get desync on almost top of the screen and with mesa 9.0 it's almost in the senter of the screen.

(In reply to comment #13)
> Well, yes, I get 60 fps with blur disabled.

Sounds like the troublemaker, try lowering the blur strength.

> But I desync lower than with
> mesa 8.0.4. I mean, on intel 3000 with RC6 enabled you get desync on almost
> top of the screen and with mesa 9.0 it's almost in the senter of the screen.
I don't understand that.
If you're talking about vsync, the idea is to have no break at all (the buffer should be changed while the screen takes a short break)

If you have a tear line despite vsync is enabled, that means that it doesn't really work - and if the tearline shifts with the version that very likely means that the subbuffy copy can not be performed during the retrace and the only working approach is a buffer swap, see bug #307965

This type of tearing is typical for Intel HD3000. There is no way (I don't know any) to bypass it in KWin, but it can be bypassed in GNOME with some Clutter parameters.
So, there is a tear line in 8.0.4, but it's on the almost top of the screen, and with 9.0 it is much lower, almost in the center.

And I got another bug, just restored minimized window of opera browser and it didn't repaint anything. I have clicked on some tabs and nothing happened, minimized and restored again and it was on that tab that I clicked last. It never happened on 8.0.4.

Screw that, switching mplayer from windowed to fullscreen mode fully hang my video adapter. I'm downgrading to 8.0.4

I've an intel 17 cpu (grapichs HD3000) and with mesa 9 I have a big performance loss. Kwin_gles is totally corrupted (continuous repainting problem). With standard kwin the present window work very bad bat If I disable blur effect, the problem is resolved.
Downgraded to mesa 8 and now kwin is fast as light.

> Kwin_gles is totally corrupted (continuous repainting problem). 
Looks like Mesa issue: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1065125

Same problems with radeon driver (GPU: ATI Mobility Radeon  x1400)

Of course with Radeon is the same problem. I have Radeon HD 2600 XT card.

launchpad bug also mentions nouveau, either the bug is in MESA or the interpretation of EGL/GLES has been changed.

arch bug on kwin:
https://bugs.archlinux.org/task/31956?project=1&order=id&sort=desc
(the screenshot there has the white lines like in bug #308245 which also mentions it's regardless of the compositor.

arch bug on chromium/gtk
https://bugs.archlinux.org/task/31915?project=1&openedfrom=-1+week

(In reply to comment #21)
> launchpad bug also mentions nouveau, either the bug is in MESA or the
> interpretation of EGL/GLES has been changed.
I yesterday installed Kubuntu 12.10 on an USB stick and tried current master in OpenGL+EGL mode on my Intel hardware. It showed the same behavior and my guess it that it picks the wrong EGL driver.

So if anyone wants to play with it: try some of the environment variables listed in http://www.mesa3d.org/egl.html

With Mesa 8 the gallium driver is chosen

Created attachment 74610 [details]
kwin_gles repainting bug

Posting a screenshot to shows the glitches

I'm having this problem on Kubuntu 12.10 and reported it on launchpad. There is some troubleshooting there (I tried different versions of mesa etc):
https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1061073

(In reply to comment #22)
> (In reply to comment #21)
> > launchpad bug also mentions nouveau, either the bug is in MESA or the
> > interpretation of EGL/GLES has been changed.
> I yesterday installed Kubuntu 12.10 on an USB stick and tried current master
> in OpenGL+EGL mode on my Intel hardware. It showed the same behavior and my
> guess it that it picks the wrong EGL driver.
> 
> So if anyone wants to play with it: try some of the environment variables
> listed in http://www.mesa3d.org/egl.html
> 
> With Mesa 8 the gallium driver is chosen

i tried exporting EGL_DRIVER to gallium in my bashrc and restarted the machine. i tried both, kwin and kwin_gles and they show the same glitches. but maybe i tested it wrong?

*** Bug 308649 has been marked as a duplicate of this bug. ***

this bug has been bisected by someone on freedesktop.org: https://bugs.freedesktop.org/show_bug.cgi?id=55998#c19

Looks like slowdown is one issue (default MSAA only on Intel) but glitches with GLES is another issue (on all Mesa drivers). Only first one has been bisected.

Git commit 6cf057777555a5d0c834de3a0165a62916cf3b40 by Fredrik Höglund.
Committed on 30/10/2012 at 18:20.
Pushed by fredrik into branch 'KDE/4.9'.

kwin/glx: Avoid MSAA configs in initBufferConfigs()

It appears that we're accidentally choosing an MSAA config with the
Intel driver in Mesa 9.0. So change the algorithm to take the values
of GLX_SAMPLES and GLX_SAMPLE_BUFFERS into account.

Found by Kenneth Graunke.

M  +20   -1    kwin/scene_opengl_glx.cpp

http://commits.kde.org/kde-workspace/6cf057777555a5d0c834de3a0165a62916cf3b40

Just thought I'd let you know I tested the patched scene_opengl_glx.cpp file with the existing Ubuntu deb source kde-workspace package and it has fixed the slow down and screen corruption issues for me. This is on a Lenovo x230 with an intel i7-3520M, Mesa 9.0, KDE Workspace 4.9.2.

Thanks.

Patch applied in kdebase-workspace (Arch Linux), as RunetMember already said, I confirm that only the slow down has been fixed.

Just to be clear. I was talking about the non-gles version of Kwin when testing. Don't know if a bug report should be created specifically for the MSAA bug which seems to be what caused the screen corruption as well as slowdown in kwin standard OpenGL.

The slowdown gone, but I have screen freeze issue now. Like, the screen is not always updated and if you click somewhere you think nothing happened but if you minimize and restore window, you see that click worked.

*** Bug 309510 has been marked as a duplicate of this bug. ***

*** Bug 308369 has been marked as a duplicate of this bug. ***

bug for gles https://bugs.freedesktop.org/show_bug.cgi?id=55856

The slowdown is gone for me except in fullscreen HD videos (either VLC or flash - 720p+). I am quite sure this is a KWin bug because I tried downgrading to Mesa 8.0.4 (which was working fine before) and I experienced the same issues. So it is something in the 4.9.2 -> 4.9.3 transition (perhaps even the above patch).

I also noticed that low resolution videos (480p) play smoothly, as well as the HD videos but only when not viewed fullscreen.

Mesa: 9.0
KDE: 4.9.3
Linux: 3.6.6
Intel Driver: 2.20.12
Intel HD Graphics 4000

(In reply to comment #37)

> I also noticed that low resolution videos (480p) play smoothly, as well as
> the HD videos but only when not viewed fullscreen.

"kcmshell4 kwincompositing", last tab. is "suspend compositing for fullscreen windows" checked? Do they play faster if you suspend compositing altogether?

(In reply to comment #38)
> (In reply to comment #37)
> 
> > I also noticed that low resolution videos (480p) play smoothly, as well as
> > the HD videos but only when not viewed fullscreen.
> 
> "kcmshell4 kwincompositing", last tab. is "suspend compositing for
> fullscreen windows" checked? Do they play faster if you suspend compositing
> altogether?

It is not checked, with KDE 4.9.2 + Mesa 8.0.4 it worked fine unchecked.

Checking it and/or disabling effects altogether caused VLC to play smoothly fullscreen.

Flash remained unaffected either way (it doesn't simply slow down, it fails to expand the video fullscreen and freezes the video).

Iff at all, rather
http://quickgit.kde.org/?p=kde-workspace.git&a=commit&h=9364f5a7579567f5ebcf537eccf6147416e0e7e0
or maybe
http://quickgit.kde.org/?p=kde-workspace.git&a=commit&h=55a2f19c8a41d9b3d13d69d7769999daf5730414

- Can you check reverting the commits?

- Sure the intel driver (xf86-video-intel) / flash / vlc/libav didn't change between "works" and "works not"?

This:
"Flash remained unaffected either way (it doesn't simply slow down, it fails to expand the video fullscreen and freezes the video)."
Smells suspicious, since with suspended compositing, kwin is actually out of game here.

- I tried reverting the commits each alone and together and the result is that the first commit introduced the VLC slowdown.

- Checking my logs, there was a google-chrome update along with KDE 4.9.3. It could be that the flash issues are totally unrelated (I am using the built-in flash player).

Just for reference:
Reverting commit 1+2: VLC is OK, Flash freezes
Reverting commit 1: VLC is OK, Flash freezes
Reverting commit 2: VLC is slow, Flash freezes

Suspending the effects for fullscreen windows stops the VLC slowdown but when another window pops up (e.g. KMix's volume indicator) it becomes sluggish again. Suspending the effects altogether produces no slowdown at all.

Yep, I can confirm that the flash issue is unrelated. External flash (11.2) works fine, please ignore the issue. Chrome 23 ships flash 11.5.

kwriteconfig --file kwinrc --group Compositing -- key GLStrictBinding true
qdbus org.kde.kwin /KWin reconfigure
then toggle compositing off / on (shift+alt+f12)

Completely suspend compositing in that case will however likely still get you the best overall performance.

@Fredrik:
the commit is not commented - what was the reason behind this (possibly related to a special driver version?)

Just updated xf86-video-intel to 2.20.13 and get lags with mplayer -vo gl fullscreen without suspending compositing for fullscreen windows. It happens only with SNA. Everything is fine with UXA.

(In reply to comment #43)
> @Fredrik:
> the commit is not commented - what was the reason behind this (possibly
> related to a special driver version?)

With DRI2 drivers there is no need to rebind the window pixmap to the texture every time the window is damaged. The texture and the pixmap reference the same memory buffer. 

This commit has no effect on the GLES backend however, since it always enables loose binding unconditionally.

@Konstantinos: are you actually running kwin_gles?

No, standard OpenGL.

The original bug is fixed with commit in comment #29, thus closing.

Regarding the video slowdown / other issues regarding non-strict binding, please check whether this is still an issue (see comment #43 and set it "false" instead of "true") and file a new bug in case.

Thanks everyone.