GNOME Bugzilla – Bug 122670
Jerky/random resizing of windows via keyboard
Last modified: 2005-11-19 17:15:35 UTC
Package: metacity Severity: minor Version: 2.4.55 Synopsis: Jerky/random resizing of windows via keyboard Bugzilla-Product: metacity Bugzilla-Component: general Description: Description of Problem: When using the keyboard interface to resize windows (Alt-F8 and then cursor keys), if the key is held down (to do a major resizing) then the enlargement of the frame becomes jerky and even reverses direction. Steps to reproduce the problem: 1. Press Alt-F8 2. Hold down (e.g. right arrow key) 3. Watch Actual Results: Frame generally expands to the right, but after a few seconds it "gets confused" and jerky, effectively stalling or even going in the wrong direction. Expected Results: Frame should expand uniformly to the right. How often does this happen? Every time. Additional Information: It would also be nicer if the default step size for this and for the Alt-F7 window-move bindings were 2 or 3 times larger. ------- Bug moved to this database by unknown@bugzilla.gnome.org 2003-09-18 17:32 ------- The original reporter (buckley@hep.phy.cam.ac.uk) of this bug does not have an account here. Reassigning to the exporter, unknown@bugzilla.gnome.org. Reassigning to the default owner of the component, metacity-maint@bugzilla.gnome.org.
Is this only with terminals and other windows with a "grid"? If so may narrow it down. Suspect that close perusal of verbose debug spew would show the problem.
*** Bug 114112 has been marked as a duplicate of this bug. ***
*** Bug 106994 has been marked as a duplicate of this bug. ***
No, this isn't just with terminals and grid apps. It happens with other windows. Currently, one has to hold down the arrow key for about a second to see this happen. I've done a little bit of investigating and have some logs hanging around somewhere....
Maybe we're getting to many requests and queued resize isn't being handled in time. Perhaps we need code to compress the resize events.
Created attachment 32623 [details] [review] A patch I was using to try to debug this problem. Here's a patch that I was using to try to debug the problem about a week ago. It appeared that I was getting somewhat close to the problem--I would generate logs with this patch when trying to make a window larger, and the first occurence of the window shrinking (i.e. "jumping back") came immediately after the ~I think this is when things are going to get hosed~ messages added by the patch.
Comment on attachment 32623 [details] [review] A patch I was using to try to debug this problem. This was just for debugging purposes, so I'm marking this patch as such. I haven't looked at this for a while, but I just thought I'd throw the patch up here in case anyone else wants to look at it before I get around to it again.
Created attachment 32726 [details] debug spew for a single keypress event while keyboard-resizing This shows it quite nicely. In particular, look at these lines grepped out of the attached spew: GEOMETRY: Move/resize 0x20000e (xterm) to 364,553 532x316 (user move/resize) from 364,553 526x316 GEOMETRY: Move/resize 0x20000e (xterm) to 364,553 526x316 (user move/resize) from 364,553 532x316 GEOMETRY: Move/resize 0x20000e (xterm) to 364,553 532x316 (user move/resize) from 364,553 526x316 GEOMETRY: Move/resize 0x20000e (xterm) to 364,553 532x316 (user move/resize) from 364,553 532x316 GEOMETRY: Move/resize 0x20000e (xterm) to 364,553 532x316 (user move/resize) from 364,553 532x316 Clearly the jerky effect is caused by the window going back and forth -- effectively doing the resize operation twice. I'm really not familiar enough with metacity yet to find the cause, but I hope this helps.
Removing the old milestone, bumping up the priority, and noting that it still happens...
[Cue Wizard of Oz music] Ding! Dong! The bug is dead! The wicked bug, The wicked bug, Ding! Dong! The wicked bug is dead...