Re: how to get rid of XFree in the longterm (just a thought)
From: Kip Rugger (kbr_at_pangea.ca)
Date: 03/23/04
- Next message: Kendall Bennett: "Re: Big problems with glibc - how to debug?"
- Previous message: Jan Knutar: "Re: Getting started in KDE"
- In reply to: Soeren Sandmann: "Re: how to get rid of XFree in the longterm (just a thought)"
- Next in thread: Alan Coopersmith: "Re: how to get rid of XFree in the longterm (just a thought)"
- Reply: Alan Coopersmith: "Re: how to get rid of XFree in the longterm (just a thought)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 23 Mar 2004 14:17:55 -0600
Soeren Sandmann <sandmann@daimi.au.dk> wrote:
>There is a scheduler inside the X server too, and that scheduler is
>actually responsible for some of the expose and resize lag that people
>complain about. The problem is that the X scheduler prioritizes the
>clients that are getting input events higher than other
>clients. That's typically good, because clients that are getting input
>events are generally those the user cares about.
>
>However, there is a pathology when you are dragging windows around or
>resizing them, because then the window manager is getting input events
>and other clients aren't, so the X server prioritizes the window
>manager above everything else, and the result is the lagging effects
>where the other clients are having their drawing requests ignored.
Interesting point. The Xserver code has a number of sections surrounded
by #ifdef SMART_SCHEDULE which would appear to implement this behaviour.
This would suggest that the opposite problem -- say a client doing some
form of continuous updating -- could preclude effective user interaction.
After all, you cannot tolerate an application locking out user control.
Maybe SMART_SCHEDULE is not smart enough. It would be interesting to
know the history of this change.
>If you renice the X server to -n, you'll make the problem worse,
>because then the other clients will not even *run* if the X server is
>runnable, which it is all the time when the user is moving windows
>around.
The nice value on must un*x systems is a bias, not an absolute priority.
Thus a small negative nice value would give the server a running start,
but would not preclude other processes from being dispatched if the
server became compute-bound.
I would avoid renice-ing anything to -20 because that is indeed the
situation that you are describing.
- Next message: Kendall Bennett: "Re: Big problems with glibc - how to debug?"
- Previous message: Jan Knutar: "Re: Getting started in KDE"
- In reply to: Soeren Sandmann: "Re: how to get rid of XFree in the longterm (just a thought)"
- Next in thread: Alan Coopersmith: "Re: how to get rid of XFree in the longterm (just a thought)"
- Reply: Alan Coopersmith: "Re: how to get rid of XFree in the longterm (just a thought)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|