Bug 310945 - New maximize effect leads to visual glitch
Summary: New maximize effect leads to visual glitch
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: effects-various (show other bugs)
Version: 4.9.80
Platform: Chakra Linux
: NOR normal
Target Milestone: 4.10
Assignee: KWin default assignee
URL:
Keywords:
: 311253 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-11-30 20:00 UTC by Fabian
Modified: 2013-02-06 23:55 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.10
Sentry Crash Report:
thomas.luebking: ReviewRequest+


Attachments
the visuial glitch (50.59 KB, image/jpeg)
2012-11-30 20:03 UTC, Fabian
Details
Picture showing the glitch appearing with KDevelop. (46.22 KB, image/jpeg)
2012-12-01 15:51 UTC, Fabian
Details
Fix attempt (1.09 KB, patch)
2013-01-25 20:05 UTC, Thomas Lübking
Details
2nd try (1.15 KB, patch)
2013-01-25 21:29 UTC, Thomas Lübking
Details
3rd try - broadsword (635 bytes, patch)
2013-01-25 22:51 UTC, Thomas Lübking
Details
Other way round (1.75 KB, patch)
2013-01-26 20:54 UTC, Thomas Lübking
Details
Semi-other-way-round (1.60 KB, patch)
2013-01-26 22:57 UTC, Thomas Lübking
Details
Semi-other-way-round v.2 (1.50 KB, patch)
2013-01-27 09:14 UTC, Thomas Lübking
Details
Semi-other-way-round v.2 (1.50 KB, patch)
2013-01-27 09:17 UTC, Thomas Lübking
Details
Last try (hopefully) (1.49 KB, patch)
2013-01-27 10:20 UTC, Thomas Lübking
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Fabian 2012-11-30 20:00:27 UTC
Unmaximizing a window while having the new maximize effect enabled causes a visual glitch (some part of the window is still visible, see the attached picture).
However, my setup is not very common as I use some applications with window border and frame disabled. And only on those I noticed the bug so far. Furthermore, I can only reliably replicate this bug with Quassel, though I managed to get hit by it twice with Firefox and once with Thunderbird. 
As soon as any other effect is applied, the visual glitch is gone.

My setup:
Qt 4.8.4
Xorg server 1.12.3
using the i915 driver

Reproducible: Always
Comment 1 Fabian 2012-11-30 20:03:23 UTC
Created attachment 75552 [details]
the visuial glitch
Comment 2 Fabian 2012-12-01 15:50:31 UTC
Correction: I can reproduce the bug now with a normal window (KDevelop), as shown in the attached picture.
Comment 3 Fabian 2012-12-01 15:51:30 UTC
Created attachment 75565 [details]
Picture showing the glitch appearing with KDevelop.
Comment 4 Thomas Lübking 2012-12-01 15:56:23 UTC
Could you please provide the output of
qdbus org.kde.kwin /KWin supportInformation
Comment 5 Fabian 2012-12-01 15:59:40 UTC
Sure: http://paste.kde.org/618044/
Comment 6 Thomas Lübking 2012-12-01 16:11:24 UTC
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.
Comment 7 Fabian 2012-12-01 16:21:06 UTC
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.
Comment 8 Thomas Lübking 2012-12-01 16:30:27 UTC
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)
Comment 9 Fabian 2012-12-01 16:38:10 UTC
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.
Comment 10 Thomas Lübking 2012-12-06 14:32:02 UTC
*** Bug 311253 has been marked as a duplicate of this bug. ***
Comment 11 Martin Flöser 2013-01-17 15:32:34 UTC
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.
Comment 12 Thomas Lübking 2013-01-17 17:05:42 UTC
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?
Comment 13 Fabian 2013-01-17 17:25:37 UTC
@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.
Comment 14 Martin Flöser 2013-01-17 18:55:12 UTC
(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.
Comment 15 Manuel Tortosa 2013-01-17 19:42:27 UTC
I use nVidia propietary drivers and i have the same issue, so that's not Intel driver related at all.
Comment 16 Thomas Lübking 2013-01-17 19:49:12 UTC
Please also attach the output of "qdbus org.kde.KWin /KWin supportInformation" (so we can check for a pattern)
Comment 17 Manuel Tortosa 2013-01-17 20:01:24 UTC
http://paste.chakra-project.org/3706/

here you go
Comment 18 Thomas Lübking 2013-01-17 20:10:42 UTC
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/ )
Comment 19 Manuel Tortosa 2013-01-17 20:17:21 UTC
Disabling OpenGL 2.0 shaders doesn't help here.
Comment 20 Manuel Tortosa 2013-01-18 21:41:25 UTC
Updated to Mesa 9.0 , same issue.
Comment 21 Thomas Lübking 2013-01-18 21:59:47 UTC
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.
Comment 22 Nikola Schnelle 2013-01-25 13:24:39 UTC
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
Comment 23 Martin Flöser 2013-01-25 13:38:09 UTC
(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.
Comment 24 Thomas Lübking 2013-01-25 14:25:31 UTC
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?
Comment 25 manutortosa@gmail.com 2013-01-25 18:07:12 UTC
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.
Comment 26 Thomas Lübking 2013-01-25 20:05:01 UTC
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.
Comment 27 manutortosa@gmail.com 2013-01-25 21:18:15 UTC
http://wstaw.org/m/2013/01/25/kwin.jpg

first attempt, no go :(   ^
Comment 28 Thomas Lübking 2013-01-25 21:29:43 UTC
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)
Comment 29 manutortosa@gmail.com 2013-01-25 22:19:29 UTC
http://wstaw.org/m/2013/01/25/kwin1.jpg

Seems worse :D
Comment 30 Thomas Lübking 2013-01-25 22:51:16 UTC
Created attachment 76724 [details]
3rd try - broadsword

Ok, let's the see whether we can do anything here at all.
Comment 31 manutortosa@gmail.com 2013-01-25 23:39:55 UTC
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.
Comment 32 manutortosa@gmail.com 2013-01-25 23:56:00 UTC
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.
Comment 33 Thomas Lübking 2013-01-26 20:04:20 UTC
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)?
Comment 34 manutortosa@gmail.com 2013-01-26 20:13:38 UTC
Yes, absolutelly, but will compile again to make sure.
Comment 35 Thomas Lübking 2013-01-26 20:54:45 UTC
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!)
Comment 36 manutortosa@gmail.com 2013-01-26 22:32:53 UTC
Ok, that worked, tested in 2 different systems by 2 different people getting the same issue.
Comment 37 Thomas Lübking 2013-01-26 22:57:30 UTC
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)
Comment 38 manutortosa@gmail.com 2013-01-27 08:37:48 UTC
With the last patch the glitch is gone, but we loose completelly the effect.
Comment 39 Thomas Lübking 2013-01-27 09:14:06 UTC
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#
Comment 40 Thomas Lübking 2013-01-27 09:17:02 UTC
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 ;-)
Comment 41 manutortosa@gmail.com 2013-01-27 10:13:33 UTC
Sorry, the last patch enables again the effect, but i can reproduce the glitch.
Comment 42 Thomas Lübking 2013-01-27 10:20:40 UTC
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.
Comment 43 manutortosa@gmail.com 2013-01-27 11:07:26 UTC
Works.
Comment 44 Thomas Lübking 2013-01-28 21:29:04 UTC
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
Comment 45 Fabian 2013-01-28 21:44:01 UTC
Applied the patch against the version from RC3, it fixes the issue here.
Comment 46 Thomas Lübking 2013-01-30 12:28:51 UTC
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
Comment 47 Thomas Lübking 2013-01-30 12:29:32 UTC
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
Comment 48 Nikola Schnelle 2013-02-06 15:16:36 UTC
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.
Comment 49 Martin Flöser 2013-02-06 15:25:50 UTC
do you still have the effect from kde-look installed? If yes: delete it
Comment 50 Nikola Schnelle 2013-02-06 15:35:20 UTC
(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.
Comment 51 Thomas Lübking 2013-02-06 17:30:35 UTC
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)
Comment 52 Nikola Schnelle 2013-02-06 17:49:24 UTC
(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.
Comment 53 Thomas Lübking 2013-02-06 18:22:48 UTC
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.
Comment 54 Nikola Schnelle 2013-02-06 18:50:36 UTC
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.
Comment 55 Thomas Lübking 2013-02-06 21:49:03 UTC
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?
Comment 56 Nikola Schnelle 2013-02-06 23:55:51 UTC
(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.