Re: metacity slowness

[Stephane Chauveau <s.chauveau@chello.nl>]

> The thing is that different people can have very 
> different perceptions of what's 'fast' and what's 'slow'. 
> I can't seem to tell much difference between metacity and 
> sawfish here (except that opaque window resizing works 
> much better with metacity :), YMMV.

The opaque window resizing problem is common to most WM.

My opinion is that this is a typical scheduling problem. 
Consider that initially, you have 3 sleeping processes: 
the app, the wm and the X11 server.

Then you start resizing.

 (1) the scheduler starts X11 which immediately sends 
     some resize events to the wm and then go back to sleep. 
 (2) the scheduler gives the hand to the wm which starts
     repainting the borders and send some redraw events to 
     the app. 
 (3) the scheduler gives the hands back to x11 because it 
     has higher priority (nice -10) and because it was the 
     last active process. 
 (4) When X11 is done with repainting the borders, then 
     the mouse is likely to have moved so X11 sends  
     more resize events to the wm. 
 (5) At this point, there are pending X events for both the 
     app and the wm and they are both sleeping. The scheduler 
     is likely to choose the wm because it was the last 
     active process. 
     Bad choice! Go back to 2 and loop until the scheduler 
     eventually decides to give the hand to the app.      
  
So why doesnt everyone see this problem?

 (a) multi-proc systems don't have the pb because more than 
     one process is running at any time. 
 (b) Systems on which X11 does not have higher priority 
     are less subject to the problem.
 (c) Systems on which any of the 3 processes are executed 
     remotely do not have this problem. For example, at 
     work, I am running an X server on a W2000 box with 
     the apps and the wm on a remote Linux server. The 
     whole system is graphicaly slower than my home PC 
     but opaque resizing is a LOT SMOTHER.   
 (d) if X11 is able to draw the window borders faster than 
     the mouse events are received (fast videocard and/or 
     slow  mouse) then at step (5) the only pending process
     will be the app and the problem disapear.  
     For information, Xev tells me that my usb mouse sends 
     about 115 motion events per second. 
 (e) All linux kernels do not have the same scheduler. The 
     behavior might be different on other systems (bsd and 
     other unixes).

I was able to solve this problem on my system by patching 
sawfish;  usleep(50000) at the end of the function 
move_resize_window_to reduces the number of redraw events
executed per seconds. The redrawing of the window borders 
is not smoother but the application is refreshed immediately.
Another advantage is that opaque redraws do not eat all the cpu 
anymore.
 
S.