Bug 324560

please post the output of
   qdbus org.kde.kwin /KWin supportInformation

GUI style is oxygen?

Created attachment 82180 [details]
qdbus output as requested

Yes, style is oxygen and gtk style used by Chromium is oxygen-gtk2.

(In reply to comment #2)
> Created attachment 82180 [details]
> qdbus output as requested

> Qt Graphics System: native
Does it also happen with the raster graphicssystem (which should be faster in that setup anyway)

> glPreferBufferSwap: 0
Does it also happen with "tearing prevention" enabled?

> Yes, style is oxygen and gtk style used by Chromium is oxygen-gtk2.
I take this does /only/ occur with chromium?

(In reply to comment #3)
> Does it also happen with the raster graphicssystem (which should be faster
> in that setup anyway)
Yes

> > glPreferBufferSwap: 0
> Does it also happen with "tearing prevention" enabled?
Doesn't happen with "Full scene repaints", does happen with anything else

> > Yes, style is oxygen and gtk style used by Chromium is oxygen-gtk2.
> I take this does /only/ occur with chromium?
I remember experiencing similar things with dolphin and some other apps (and this was since about 4.7 or earlier), but they were hard to reproduce. Chromium appeared to give a 100% reproducible case, so now I actually made a report.

> > > glPreferBufferSwap: 0
> > 
> > Does it also happen with "tearing prevention" enabled?
> 
> Doesn't happen with "Full scene repaints", does happen with anything else
hmm sounds like an update is missing or using the wrong region. Assuming it's 
an Unmanged:
addWorkspaceRepaint(visibleRect());  // damage old area
QRect old = geom;
geom = newgeom;
addRepaintFull();

visibleRect() should include the shadow unless it's totally broken.

And Toplevel::addRepaintFull()

void Toplevel::addRepaintFull()
{
    repaints_region = visibleRect().translated(-pos());
    emit needsRepaint();
}

So this looks right to me, too.

There's probably more going on than just a configure notification, probably some extra shape or shadow re-setting.

It's however reproducible here, i'll print me some debug out.

Major issue:

diff --git a/kwin/composite.cpp b/kwin/composite.cpp
index 8489373..d70597c 100644
--- a/kwin/composite.cpp
+++ b/kwin/composite.cpp
@@ -1011,7 +1011,7 @@ void Toplevel::addDamageFull()
         return;
 
     damage_region = rect();
-    repaints_region = rect();
+    repaints_region |= rect();
 
     emit damaged(this, rect());
 }

There's a follow-up damage event (of the window) which replaces the visibleRect() repaint.

But this still cuts off the right side of the shadow (probably for a completey different reason, though)

Created attachment 82287 [details]
actual fix

the other issue is that the shadow region is not updated before calling addRepaintFull (so the shadow area is too small and doesn't extend the bounding rect on the right)

ShipIt(tm)

Git commit db3d4eed1cd5e5da2b737b254895191af951bab8 by Thomas Lübking.
Committed on 11/09/2013 at 21:27.
Pushed by luebking into branch 'KDE/4.11'.

fix two damage artifact causes

1. when adding a full damange, that must not replace existing (larger) repaints
2. emit geometryChanged before invoking and to update shadowGeometry through addRepaintFull
FIXED-IN: 4.11.2

M  +1    -1    kwin/composite.cpp
M  +1    -0    kwin/events.cpp

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