Bug 149997

Summary:	KWin locks up if rubberband resize is selected
Product:	[Plasma] kwin	Reporter:	Luciano Montanaro <mikelima>
Component:	general	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	RESOLVED FIXED
Severity:	crash
Priority:	HI
Version:	unspecified
Target Milestone:	---
Platform:	Compiled Sources
OS:	Linux
Latest Commit:		Version Fixed In:

Description Luciano Montanaro 2007-09-19 10:57:42 UTC

Version:            (using KDE Devel)
Installed from:    Compiled sources
Compiler:          4.1.2 
OS:                Linux

When using non-solid resize, the rubberband code tries tio access the desktopWidget() (or the workspaceWidget() from decoration code). I've found that kwin freezes as soon as the workspaceWidget() method is called. It is not even necessary to actually try to draw on the widget.

I discovered this when trying to fix the rubberband code in the B2 decoration. I re-enabled the needed code, using what I think are the needed changes. Previously, the drawbounds() method simply returned true (well it did some calculations and then returned true) without attempting to draw anything.

Comment 1 Luciano Montanaro 2007-10-17 10:58:14 UTC

I tried again and I managed to get some more information about this.
Qt prints this when I try to resize the window:
QPainter::begin: Widget painting can only begin as a result of a paintEvent

KWin outputs a few lines like the above, and then Blocks.

Actually, I can see the above only after I kill kwin from a console.

So the problem is that we cannot really paint on the Desktop widget, after all.

Maybe creating a transparent widget for this could be an option, but probably the API for this would need to change. I'm probably the only one reimplementing rubber band, so it should not be a big problem.

Comment 2 Luciano Montanaro 2007-11-15 12:03:53 UTC

This is not likely to be fixed for KDE4.0.
Wouldn't it be better to hide the
 "Show Contents of Moving Windows" 
and 
"Show Contents of Resizing Windows" 
checkboxes for now, and ignore the settings?

The alternative would be a freezed desktop for everyone that upgrades to KDE4 and who has set the option themselves...

Unless there is an easy fix for this issue.

Comment 3 Lubos Lunak 2007-11-20 17:01:10 UTC

SVN commit 739136 by lunakl:

Make the outline for moving/resizing work with Qt4, which bothers
to support XOR painting only when XRender is available. Given that
outline should be mainly used with older systems, go for a DIY Xlib-based
solution. Needs changes in decorations using it.
BUG: 149997



 M  +0 -5      bridge.cpp  
 M  +0 -1      bridge.h  
 M  +2 -1      clients/b2/b2client.cpp  
 M  +9 -4      geometry.cpp  
 M  +0 -5      kcmkwin/kwindecoration/preview.cpp  
 M  +0 -1      kcmkwin/kwindecoration/preview.h  
 M  +2 -6      lib/kdecoration.cpp  
 M  +20 -9     lib/kdecoration.h  
 M  +0 -1      lib/kdecoration_p.h  
 M  +0 -5      tools/decobenchmark/preview.cpp  
 M  +0 -1      tools/decobenchmark/preview.h  
 M  +0 -16     workspace.cpp  
 M  +0 -3      workspace.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=739136