Bug 310945

Created attachment 75552 [details]
the visuial glitch

Correction: I can reproduce the bug now with a normal window (KDevelop), as shown in the attached picture.

Created attachment 75565 [details]
Picture showing the glitch appearing with KDevelop.

Could you please provide the output of
qdbus org.kde.kwin /KWin supportInformation

Sure: http://paste.kde.org/618044/

Can you try to cause this with kwin (ie. not gles) and esp. w/o opengl 2.0 shader support.
If that does not expose the problem, deactivate the zoom effect and try again.

I'm not sure if I did this correctly: I run kwin --replace, and could still reproduce the problem. Actually it increased the possibility for it to happen. However, I'm not sure if the above command sufficed to ensure that the non gles version is running. Additionally, I'm not sure which effect should be deactivated, could  you give the exact name? If it is "Maximize"; Description: "Animation for a window going to maximize/restore from maximize", I deactivated it and that helps, both with normal kwin and with kwin_gles.

Sorry ;-)

"kwin --replace&" will launch the GLX version, yes.
Next, run "kcmshell4 kwincompositing" and deactivate the "OpenGL 2.0" shaders in the last tab (that's important in this regard)

The effect that might be the (additional) culprit is the one that zooms the entire desktop when pressing Meta++ or Meta+- (the global magnifier)

Unfortunately the glitch still persists after deactivating deactivating OpenGL 2.0 shaders and deactivating the global magnifier, with both kwin and kwin_gles. Having the maximize effect disabled will obviously prevent the glitch.

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

It's only a recommendation I can give: update the mesa drivers. You are still on Mesa 8 while Mesa 9 has been out for quite a while now.

Can you eventually try (with rc2, not before!) animated resizes with http://sourceforge.net/projects/bekwinfx/ (you only need be.animated) and check whether the same glitches occur?

@Thomas Lübking: While being a bit overly wobbly :-), the effect seems to work just fine. On the other hand, with normal use I nowadays notice the glitch very seldom (using kwin without gles). Though I can still reproduce it, by quickly changing the maximization state.

@Martin Gräßlin: While this is not up to me (alone), I will propose this to my distribution. If you think that it is related, I think  the bug should be set to NEEDSINFO, until it can either confirmed or refuted.

(In reply to comment #13)
> @Martin Gräßlin: While this is not up to me (alone), I will propose this to
> my distribution. If you think that it is related, I think  the bug should be
> set to NEEDSINFO, until it can either confirmed or refuted.
I'm not sure whether it is related - it might be, it might not. Especially Intel drivers are sometimes problematic, so the latest version might help.

I use nVidia propietary drivers and i have the same issue, so that's not Intel driver related at all.

Please also attach the output of "qdbus org.kde.KWin /KWin supportInformation" (so we can check for a pattern)

http://paste.chakra-project.org/3706/

here you go

Can you check whether it happens when you deactivate the OpenGL 2.0 shaders (because together with the zoom effect ever being invoked, this will be absolutely reproducible, see http://git.reviewboard.kde.org/r/108252/ )

Disabling OpenGL 2.0 shaders doesn't help here.

Updated to Mesa 9.0 , same issue.

mesa version is close to irrelevant on the nvidia blob.

Try disabling vsync (the uncleared area is equally high on both scrots and the cap is only vertical - there're no horizontal relicts!)

Otherwise my next try would be to deactivate all other effects and check whether the issue remains and also try the xrender backend.

If it's vsyncing: https://git.reviewboard.kde.org/r/107198/
It does not work without that patch on nvidia systems anyway.

I can reproduce this with Google Chrome on Kubuntu 12.04 KDE 4.9.5 and maximize effect from kde-look.
I use latest opensource radeon driver and latest stable mesa (9.0.2).

Video of the bug: http://www.sendspace.com/file/4wyb4g

(In reply to comment #22)
> I can reproduce this with Google Chrome on Kubuntu 12.04 KDE 4.9.5 and
> maximize effect from kde-look.
it's not exactly the same effect as shipped in 4.10. I did some API adjustements after writing the effect, so there might be differences.

API forth or back, this should not happen.
It means that the AnimationEffect causes insufficient repaints.

While i never saw this i'd immediately point postPaintScreen to have to call the it.key()->addLayerRepaint(it->second); loop also *before* updateLayerRepaints();

Who's able to try a patch?

We can give you as much testing support as needed,  just paste here the patch or enter at #chakra-devel  at Freenode so we can play around it.

Created attachment 76720 [details]
Fix attempt

That's the stuff i like to here.

I'll be around for the next 4h and certainly available on Saturday as well.

http://wstaw.org/m/2013/01/25/kwin.jpg

first attempt, no go :(   ^

Created attachment 76723 [details]
2nd try

Be not afraid, here comes a differen approach (the patches have the same name and look very similar, yet are different)

http://wstaw.org/m/2013/01/25/kwin1.jpg

Seems worse :D

Created attachment 76724 [details]
3rd try - broadsword

Ok, let's the see whether we can do anything here at all.

http://wstaw.org/m/2013/01/26/kwin2.jpg

No dice. I can even move the window and as can be seen the trash persists until the window looses the focus.

Sorry, forget the last comment, i did installed a wrong package :D, the last patch does fixes completelly the issue, so we are in the good path.

Thanks for the update and sorry for the delay.
Can you confirm that you were using the right package with the second patch (with partial scene repaints instead of layer repaints)?

Yes, absolutelly, but will compile again to make sure.

Created attachment 76741 [details]
Other way round

Unlikely required.

The new patch is a bit different and tweaks around in the "maximize" effect itself (nevertheless what you observe should not happen, but if this works i'll have a better idea what's broken)

Please reset all former patches, ie "git reset --hard HEAD" (unless you've commited or other unstashed local patches!)

Ok, that worked, tested in 2 different systems by 2 different people getting the same issue.

Created attachment 76744 [details]
Semi-other-way-round

So we got us a hook and a solution (just in case)

Can you please also try thist last one (it'll just change the order of translation/scale but still use translate and scale directly instead of asking for position and size and having the backend to the parameter resolution)

With the last patch the glitch is gone, but we loose completelly the effect.

Created attachment 76749 [details]
Semi-other-way-round v.2

Sorry - i should have tested instead of assuming that shifting some lines would not end in a desaster with JS bracket stacing ;-?+0#

Created attachment 76751 [details]
Semi-other-way-round v.2

Sorry - i should have tested instead of assuming that shifting some lines would not end in a desaster with JS bracket stacking ;-)

Sorry, the last patch enables again the effect, but i can reproduce the glitch.

Created attachment 76752 [details]
Last try (hopefully)

No need to be sorry.
This patch keeps the juggle and translation, but replaces "Scale" by "Size" parameter.

After that i should know where to take a close look =)

Thanks for your help.

Works.

https://git.reviewboard.kde.org/r/108650/

Patch is in JavaScript - *anyone* can test it by applying the diff on /usr/share/apps/kwin/effects/kwin4_effect_maximize/contents/code/maximize.js

Applied the patch against the version from RC3, it fixes the issue here.

Git commit a22ac6cb530669cdd84d17afdf87e7120009b8d1 by Thomas Lübking.
Committed on 28/01/2013 at 22:19.
Pushed by luebking into branch 'KDE/4.10'.

use Size instead of Scale animation
FIXED-IN: 4.10
REVIEW: 108650

M  +5    -5    kwin/effects/maximize/package/contents/code/maximize.js

http://commits.kde.org/kde-workspace/a22ac6cb530669cdd84d17afdf87e7120009b8d1

Git commit ded9ad74273c8e70d10138922295f2ef9d040329 by Thomas Lübking.
Committed on 28/01/2013 at 22:19.
Pushed by luebking into branch 'master'.

use Size instead of Scale animation

M  +5    -5    kwin/effects/maximize/package/contents/code/maximize.js

http://commits.kde.org/kde-workspace/ded9ad74273c8e70d10138922295f2ef9d040329

Well this is strange.

I experienced this bug with kde 4.9.5 and maximize effect from kde-look.
Then I upgraded to kde 4.10rc3 and I didn't experience this bug.
Now I am using KDE 4.10 final and I am again experiencing this bug in fullscreen smplayer: http://www.sendspace.com/file/x93kzy 

Btw I am using the lastest stable kernel, latest stable opensource radeon driver and mesa. Kubuntu 12.04 KDE 4.10.0.

do you still have the effect from kde-look installed? If yes: delete it

(In reply to comment #49)
> do you still have the effect from kde-look installed? If yes: delete it

No, I deleted it. But I think it doesn't matter anyway because since I upgraded to rc3 I am using Kubuntu with new user so I have new clean config files. Bug appeared today after I upgraded to 4.10 final. 

Just to be sure, I made new user few minutes ago and again I can repoduce this bug with smplayer and 4.10 final. 

So:
1) With kde 4.9.5 + maximize effect from kde-look I could reproduce the bug with google chrome
2) With kde 4.10rc3 I could't reproduce this bug 
4) With kde 4.10 final I can again reproduce the bug with smplayer (in rc3 it was ok). When I turn the effect off, glitch in fullscreen smplayer goes away.

Nobody actually knows what causes this issue (yet) for some people.

Experiencing it in 4.9.5, not in rc3 but again in 4.10 sounds strange - at least contradits the other feedback.

a) your video shows (undecorated) chromium, but now you talk about smplayer and esp. "glitch in fullscreen smplayer" - please ensure that this is actually the same issue (screenshot?) - "fullscreen" should unlike "maximize" not be affected by the effect at all and a glitch in the fullscreen mode esp. not (since fullscreen smplayer would play back a lot)

Do you use another script to suspend compositing with smplayer going to fullscreen or do you eventually (likely?, i think ubuntu sets this) suspend compositing for fullscreen windows (kcmshell4 kwincompositing, 3rd tab)

(In reply to comment #51)
> Nobody actually knows what causes this issue (yet) for some people.
> 
> Experiencing it in 4.9.5, not in rc3 but again in 4.10 sounds strange - at
> least contradits the other feedback.
I am reporting what I am seeing :) I had this bug 4.9.5 (with chome) then upgraded to 4.10rc3 and bug was gone (with new user, clean configs), and now in 4.10 final i can see it in fullscreen smplayer.
> 
>but now you talk about smplayer
> and esp. "glitch in fullscreen smplayer" - please ensure that this is
> actually the same issue (screenshot?) - 
Video of "fullscreen smplayer" bug: http://fs05n4.sendspace.com/dl/659c9f2cc01b40953380f44dea1728eb/511296ae4d9dd55d/x93kzy/out.ogv

> Do you use another script to suspend compositing with smplayer going to
> fullscreen 
No.

>or do you eventually (likely?, i think ubuntu sets this) suspend
> compositing for fullscreen windows (kcmshell4 kwincompositing, 3rd tab)
No.

thats not the same bug at all, there artifacts in the black area of smplayer after increasing it to fullscreen, not relicts when dropping out of maximization. (could be related to a restack, iirc those are 2 windows in smplayer)
nevertheless please check whether the maximize effect is actually involved (i'm atm not sure why it would animate the fullscreen movement) and esp. whether this happens when you alter compositor (-> xrender) and mplayer video sync (you're using?) - could be concurrent framebuffer access.

After more testing I noticed this:

1) When I play movie in non maximazed smplayer window, and then press F for full screen, smplayer goes to full screen without maximize effect (doesn't animate the fullscreen movement) and then there are no artifacts. 
2) When movie is played in maximized smplayer window and F is pressed for fullscreen, then maximize effect kicks in and then there are artifacts in fullscreen.
3) When using vlc player maximize effect never kicks in.
4) When maximize effect is turned off, there is no artifacts in smplayer fullscreen video playback.

So this problem is only present in smplayer when going from maximized window to fullscreen. In this transition maximize effect kicks in and artifacts are left around video. What is interesting is that:
1) In 4.10rc3 I didn't see artifacts in fullscreen although animated fullscreen movement was also present
2) Other players (vlc and gnome-mplayer) are not affected (maximize effect never kicks in). 

So maybe this is bug in smplayer.

Bug seems at least related then.
smplayer will likely unmaximize the regular window and at the same time display the fullscreen window.
The unmaximization causes an artifact on the fullscreen window.

Are you still able to reproduce this with anything else?

(In reply to comment #55)
> Are you still able to reproduce this with anything else?

I tried hard with many different applications, and answer is no. Only smplayer on above described way produce artifacts.