> This only happens after cycle off/on desktop effect that I need to do because of the vsync not 
> enabled on login on nvidia (Bug 322060)

Interesting detail, but should no longer be required (triple buffer detection should be fixed, please compare the ouput of
            qdbus org.kde.kwin /KWin supportInformation | grep -i block

On bug:

- Does it also happen if you restart "kwin --replace &" at runtime?
- Can you provide a screenshot?
- Can you check whether you enter
    if (--s_textureObjectCounter == 0 && s_fbo) {
        glDeleteFramebuffers(1, &s_fbo);
        s_fbo = 0;
    }

in GLTexturePrivate::~GLTexturePrivate() in libkwineffects/kwingltexture.cpp when suspending the compositor?

Created attachment 82678 [details]
Window corruption when opening queue window in HandBrake

(In reply to comment #1)
> > This only happens after cycle off/on desktop effect that I need to do because of the vsync not 
> > enabled on login on nvidia (Bug 322060)
> 
> Interesting detail, but should no longer be required (triple buffer
> detection should be fixed, please compare the ouput of
>             qdbus org.kde.kwin /KWin supportInformation | grep -i block

This is the output at first login time (kwin4_effect_showfps shows ~94 fps should be at 60):
Painting blocks for vertical retrace:  yes

> 
> On bug:
> 
> - Does it also happen if you restart "kwin --replace &" at runtime?

No, it does not happens (kwin4_effect_showfps shows ~94 fps should be at 60):
Painting blocks for vertical retrace:  no


> - Can you provide a screenshot?
$ qdbus org.kde.KWin /Compositor suspend
$ qdbus org.kde.KWin /Compositor resume

Yes, attached. Only for the fixed case on window opening from Handbrake. For window movement, screenshot with timeout does not capture the bug.

> - Can you check whether you enter
>     if (--s_textureObjectCounter == 0 && s_fbo) {
>         glDeleteFramebuffers(1, &s_fbo);
>         s_fbo = 0;
>     }
> 
> in GLTexturePrivate::~GLTexturePrivate() in libkwineffects/kwingltexture.cpp
> when suspending the compositor?

How I can do this? recompiling with some flag?

The only messages I see on suspend are:
kwin(9395) KWin::EffectsHandlerImpl::unloadEffect: EffectsHandler::unloadEffect : Unloading Effect :  "kwin4_effect_magnifier"
<above-msg-for-each-loaded-effect>
kwin(9395) KWin::Compositor::releaseCompositorSelection: Releasing compositor selection

Created attachment 82680 [details]
window outside borders on move

(In reply to comment #3)

> This is the output at first login time (kwin4_effect_showfps shows ~94 fps
> should be at 60):

Please attach the entire output of "qdbus org.kde.kwin /KWin supportInformation" and the output of "xrandr -q". You're not syncing not run a 100Hz screen.

----

> > - Does it also happen if you restart "kwin --replace &" at runtime?
> 
> No, it does not happens
I meant the glitches/artifacts/garbaged textures

 (kwin4_effect_showfps shows ~94 fps should be at 60):

> Yes, attached. Only for the fixed case on window opening from Handbrake.

The second screenshot indicates that the texture isn't cleared (the issue that clearing orignally fixed) the first one is however confusing:
It seems the "Handbrake" window would be above the "Handbrake Queue" window and by this the corruption would be either in the framebuffer or in the window texture, not the decoration texture?

- Does this also happen if you set the tearing prevention to "full repaints"?
- Is running Handbrake mandatory to cause the corruption?

> How I can do this? recompiling with some flag?

Either set a breakpoint and run kwin in gdb (from VT1) or inject a line

if (--s_textureObjectCounter == 0 && s_fbo) {
   qDebug() << "------------- Deleting s_fbo";
   glDeleteFramebuffers(1, &s_fbo);
   s_fbo = 0;
}

Latter is simpler ;-)

(In reply to comment #5)
> (In reply to comment #3)
> 
> > This is the output at first login time (kwin4_effect_showfps shows ~94 fps
> > should be at 60):
> 
> Please attach the entire output of "qdbus org.kde.kwin /KWin
> supportInformation" and the output of "xrandr -q". You're not syncing not
> run a 100Hz screen.

xrandr :    1920x1200      60.0*+   59.9

Offtopic: I now workaround the fps vs hz issue so fps is always at 60fps (TripleBuffer On + KWIN_TRIPLE_BUFFER=1 since autodetection fails sometimes). Anyway I can still reproduce the corruption...

> 
> ----
> 
> > > - Does it also happen if you restart "kwin --replace &" at runtime?
> > 
> > No, it does not happens
> I meant the glitches/artifacts/garbaged textures

Nothing. No corruptions during restarting kwin. Indeed restating kwin fixes the issue until I do again a cycle of suspend/resume composition.

> 
>  (kwin4_effect_showfps shows ~94 fps should be at 60):
> 
> > Yes, attached. Only for the fixed case on window opening from Handbrake.
> 
> The second screenshot indicates that the texture isn't cleared (the issue
> that clearing orignally fixed) the first one is however confusing:
> It seems the "Handbrake" window would be above the "Handbrake Queue" window
> and by this the corruption would be either in the framebuffer or in the
> window texture, not the decoration texture?
> 

I am not expert here. How to know about this?

> - Does this also happen if you set the tearing prevention to "full repaints"?

Yes.

> - Is running Handbrake mandatory to cause the corruption?

Yes for corruption.
but the message "kwin(17471) KWin::checkGLError: GL error ( update texture ): "GL_INVALID_OPERATION" appears for any new window opened (no corruption).

> 
> > How I can do this? recompiling with some flag?
> 
> Either set a breakpoint and run kwin in gdb (from VT1) or inject a line
> 
> if (--s_textureObjectCounter == 0 && s_fbo) {
>    qDebug() << "------------- Deleting s_fbo";
>    glDeleteFramebuffers(1, &s_fbo);
>    s_fbo = 0;
> }
> 
> Latter is simpler ;-)

OK. Recompiled with gDebug()...
1) Nothing shows in kwin output when suspend compositor for first time on login.
2) If I restart kwin (kwin --replace& @ Konsole), then suspend compositor again, message appears.  I can suspend/resume again and again... and message appears. In this case there is no corruption or message about GL_INVALID_OPERATION on any window opening.
3) Doing some tests, trying to make kwin fails in case (2), I found at least one way.
a) kwin --replace &
b) qdbus org.kde.KWin /Effects loadEffect kwin4_effect_showfps
c) qdbus org.kde.KWin /Effects unloadEffect kwin4_effect_showfps
d) qdbus org.kde.KWin /Compositor suspend
e) qdbus org.kde.KWin /Compositor resume

(c) Is optional with or without this kwin fails (no Deleting) on suspend.
(d) The only message after all effects are unloaded is: "kwin(27477) KWin::Compositor::releaseCompositorSelection: Releasing compositor selection"
(e) Apart of normal messages (attached) kwin shows this: kwin(27477) KWin::checkGLError: GL error ( PostPaint ):  "GL_INVALID_OPERATION"

The only way to fix kwin again is reexecuting it.

Created attachment 82693 [details]
qdbus org.kde.kwin /KWin supportInformation

Created attachment 82694 [details]
qdbus org.kde.KWin /Compositor resume #Normal behaviour

(In reply to comment #6)

> Offtopic: I now workaround the fps vs hz issue so fps is always at 60fps
Ok, still the effects should not run > 60Hz given your setup (on 4.11.2, on 4.11.1 - could very much be possible)
Also the autodetection should no longer fail in this version (and didn't for the attached supportInformation)
~/.xsession-errors should contain information about the detection (whether and by how many ms delay of buffer swapping it failed) and whether syncing is turned off for it.

> 3) Doing some tests, trying to make kwin fails in case (2), I found at least
> one way.

Thanks alot. The showfps effect leaks a texture, i can see it -> gonna add a patch.

This also pretty much explains it - if the fbo isn't freed/recreated it will end up being invalid, getting you a GL error and no texture clearing. Operating on the invalid fbo can then very well cause graphical corruption.

Do you start the showfps effect with the session? (It's been my testcase for the wrong TB detection, for it caused that for sure, but no more after the last patch on bug #322060 was applied)

patch:
https://git.reviewboard.kde.org/r/113136/diff/raw/

(In reply to comment #9)
> (In reply to comment #6)
> 
> > Offtopic: I now workaround the fps vs hz issue so fps is always at 60fps
> Ok, still the effects should not run > 60Hz given your setup (on 4.11.2, on
> 4.11.1 - could very much be possible)
> Also the autodetection should no longer fail in this version (and didn't for
> the attached supportInformation)
> ~/.xsession-errors should contain information about the detection (whether
> and by how many ms delay of buffer swapping it failed) and whether syncing
> is turned off for it.
> 

You are right, maybe during many test I made, I was something mixed thing. Always start ok without forcing.

> > 3) Doing some tests, trying to make kwin fails in case (2), I found at least
> > one way.
> 
> Thanks alot. The showfps effect leaks a texture, i can see it -> gonna add a
> patch.
> 
> This also pretty much explains it - if the fbo isn't freed/recreated it will
> end up being invalid, getting you a GL error and no texture clearing.
> Operating on the invalid fbo can then very well cause graphical corruption.
> 
> Do you start the showfps effect with the session? (It's been my testcase for
> the wrong TB detection, for it caused that for sure, but no more after the
> last patch on bug #322060 was applied)

Nice!. During tests was started manually sometimes and other automatically. (I used it to qucikly know the right fps, when I did not have triple buffer enabled) Definitively, it was the problem. I am going to test patch now. Thanks you!

Perfectly. Works now really good. Thanks.

See? It's not a regression, but a very sophisticated leak detection system ;-)

(In reply to comment #13)
> See? It's not a regression, but a very sophisticated leak detection system
> ;-)

Hehehe. Absolutelly. Good work ;)

Git commit aed179611d5d51264c79159311385cf5bfedd1c4 by Thomas Lübking.
Committed on 06/10/2013 at 20:58.
Pushed by luebking into branch 'KDE/4.11'.

don't leak fpstext texture
FIXED-IN: 4.11.3
REVIEW: 113136

M  +1    -3    kwin/effects/showfps/showfps.cpp
M  +1    -1    kwin/effects/showfps/showfps.h

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