Bug 149997 - KWin locks up if rubberband resize is selected
Summary: KWin locks up if rubberband resize is selected
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: HI crash
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-09-19 10:57 UTC by Luciano Montanaro
Modified: 2007-11-20 17:01 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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