GNOME Bugzilla – Bug 109362
Remove deltas during move and resize
Last modified: 2004-12-22 21:47:04 UTC
Currently, during moving and resize metacity tries to put a cap on the framerate: if (!check_moveresize_frequency (window) && ABS (dx) < resize_threshold && ABS (dy) < resize_threshold) return; however as the FIXME says, this is bogus because the dx and dy are distance from the grab point and so, this will only actually cap the framerate when you are close to the point you initially grabbed the window. The effect is noticable and bad: moving a window around near the grab point is jerky. When you move away from the grab point, window movement is smooth. I'd suggest to just do away with the frame rate capping, but if you think it is a good idea, then it should be commented out until someone actually makes it work with the correct deltas. I am attaching a patch that removes the relevant code.
Actually, I changed my mind. I think it _is_ a good idea to put a cap on the frame rate, but only when we are not using XSYNC, and only during resize, not during move.
Created attachment 15244 [details] [review] patch to remove deltas
And of course, I overlooked that calling check_moveresize_frequency() is essential for the XSYNC thing to work. New patch coming up.
Created attachment 15245 [details] [review] New patch
That looks good to me (maybe clean up the whitespace changes that don't do anything). If you tested it and it seems sane I'd say put it on gnome-2-2 in addition to HEAD.
Fri Mar 28 14:13:37 2003 Soeren Sandmann <sandmann@daimi.au.dk> * src/window.c (update_resize): Only cap refresh rate when not using SYNC. Remove bogus update-if-we-moved-more-than-a-delta. * src/window.c (update_move): Don't cap refresh rate during moves. Remove bogus update-if-we-moved-more-than-a-delta.
Actually, I see there is a problem. Capping the refresh rate doesn't work: what if the last motion event is ignored? Then the window will have the wrong size until you release the button. That didn't happen before by accident because motion events were only ever ignored for the first 30 pixels.
I committed the patch below to gnome-2-2. This disables refresh rate capping and makes sure the behavior isn't _worse_ than before. For HEAD, we'll have to schedule an update_resize() to be run at the time we would otherwise not ignore a motion event, and unschedule it every time an event is not ignored. The same problem exists when using SYNC. If an application stops updating the counter, you can move the mouse for a second without anything happening until you release the button. I think scheduling an update_resize() will work for that case too. The patch I committed: @@ -6304,8 +6304,7 @@ update_resize (MetaWindow *window, break; } - if (!check_moveresize_frequency (window)) - return; + check_moveresize_frequency (window); old = window->rect;
Makes sense to me.
Sat Jun 19 02:21:08 2004 Soeren Sandmann <sandmann@daimi.au.dk> Fix bug 143333, support for update counter spec, and 109362, schedule compensation events when events are ignored. * src/display.c (meta_display_open): Add _NET_WM_SYNC_REQUEST and _NET_WM_SYNC_REQUEST_COUNTER atoms. Remove the old METACITY_SYNC_COUNTER stuff. (meta_display_begin_op): Setup the sync counter * src/xprops.c, src/xprops.h, src/window-props.c, src/display.h: Add new atoms. * src/window.c (send_sync_request): new function. (meta_window_move_resize_internal): send a sync request before resizing. (check_move_resize_frequence): Rework logic to also check the SYNC case. If an event is ignored return the remaining time. (update_resize_timeout): Timeout that gets called when a compensation event is scheduled. (uddate_resize): schedule compensation events when an event is ignored. (meta_window_handle_mouse_grap_op_event): When an alarm is received and sync was turned off, turn it back on. * src/window.h (struct MetaWindow) Add some variables