Kernel scheduling algorithm and X.Org performance

[Soeren Sandmann]

"Dmitry Shatrov" <erdizz at rambler.ru> writes:

> Good day, xorg list. If you think this worths another list please
> redirect me.

The interesting scheduler is not only the one in the kernel, but also
the one in X itself. When you drag a window around, this is what
happens:

- mouse interrupt

- X sends motionnotify to window manager

- window sends ConfigureWindow to X server

- X server moves the window, repaints background of uncovered area,
  sends expose events to clients, including the window manager

- clients generally start repainting themselves

- while this goes on, another mouse interrupt happens

- X server sends motionnotify to window manager

- at this point, X *decides to draw the window manager frames first*, 
  because it has a "smart scheduler" that prioritizes clients getting
  input events over everything else, and the window manager is the
  only client getting input events.

So, if the window manager can't keep up with the stream of mouse
events, all the applications will _never_ have their drawing requests
executed. Even if the window manager is just a little slow to draw, 
most of the time will still be spent painting window frames.

In this mail:
  
     http://mail.gnome.org/archives/wm-spec-list/2002-December/msg00025.html

I do the math. The conclusion is that the lag n, measured in number of
mouse events, is going to be 

           n = P_a / (M - P_f)

where P_a is the time to draw all the applications, M is the time
between successive mouse events and P_f is the time to paint the
window frames. This means that as P_f tends to M, the lagging tend to
infinity - ie., you get the eraser-effect.


Søren