Resizing columns is slow/buggy

[GoogleCodeExporter]

What steps will reproduce the problem?
1. start two programs
2. move one to the left/right
3. try to resize the column bar with the mouse.

What is the expected result? What do you see instead?

I expect the column bar to move freely and the windows resize when I 'let go' 
of the bar.  Instead, I think, the windows try to resize while I'm moving the 
column bar, but far too aggressively and the whole process ends up feeling 
slow/buggy.

What version of the product are you using (wmii -v)? On what operating
system (uname -a)?

wmii-hg2776+, ©2010 Kris Maglione
Linux awagner 2.6.33.6-147.2.4.fc13.x86_64 #1 SMP Fri Jul 23 17:14:44 UTC 2010 
x86_64 x86_64 x86_64 GNU/Linux

I've attached a patch that seems to fix the problem for me.

Original issue reported on code.google.com by awagne...@gmail.com on 12 Aug 2010 at 3:35

Attachments:

• column_move_fix.patch

[GoogleCodeExporter]

I don't have this problem, and I also don't understand your suggestion. I'm 
assuming (based on your patch) that you're talking about Mod-RightMouse 
resizing. In that case, the only windows that are moved or resized while you 
drag the mouse are the drag indicator windows. I haven't tested your patch, but 
from what I can see, it should cause the horizontal indicator bar to remain 
stationary until you release the mouse, which is not the desired behavior. 
Moreover, the operation is cheap and shouldn't cause problems on even very slow 
systems (and certainly no more than the previous statement), unless perhaps 
your configuration has some issue with drawing X window borders.

So, that said, can you post the full output of `xdpyinfo -ext all`. Are you 
using any kind of compositing manager or transparent windows?

Original comment by maglion...@gmail.com on 12 Aug 2010 at 4:20

[GoogleCodeExporter]

This is just basic column movement (I wasn't aware there was a Mod-RightMouse 
resize).  I'm using my patched version now and the vertical resize bar does 
still move while I'm dragging it, though the windows on either side do not 
resize till I've let go.

It is possible I may have some graphics issue on my machine, however, I do not 
experience this sort of slow down while resizing windows in gnome/kde.  I'm 
running a MacBook Pro, and I'm booting through rEFIt, so I think my graphics 
drivers are operating sub-optimally.

I've attached the output of that command, as you suggested.  I'm not using any 
compositing manager or transparent windows.

Also, I've not much experience programming for X, or programming C for that 
matter, but if there is anything else I can send that would be helpful, please 
let me know.  In the mean time, it does seem to work better for me, though I'll 
know for sure when I try it out on my big monitor at work tomorrow where the 
issue is at it's worst.

Original comment by awagne...@gmail.com on 12 Aug 2010 at 4:51

Attachments:

• xdpyinfo_output

[GoogleCodeExporter]

Ok, I take that back, apparently it was a fluke that my system was working 
better, because it's back to it's old buggy self again.  I don't really know 
how to describe it other than when I resize it I can see lines stretched across 
the area I've dragged the column bar.  Almost as if it's not fully 
drawn/cleared the line before it draws it again.  Sorry for being vague again, 
is there some sort of debug mode I can put wmii in so I can send you something 
more useful than my descriptions of the problem?

Original comment by awagne...@gmail.com on 12 Aug 2010 at 4:58

[GoogleCodeExporter]

One more thing I noticed, when things seem to be running slow, my window titles 
have the word "(wedged)" prefixing what they are normally called.  This hangs 
around for a few seconds, then it goes away and my computer starts to respond 
again.

Original comment by awagne...@gmail.com on 12 Aug 2010 at 5:22