Jouni Tulkki <[EMAIL PROTECTED]> writes:
> Hello
>
> I have experimented with lwm (light weight window manager). I had noticed
> that moving windows with the mouse so that window position is updated
> immediately when mouse is moved was slow. After trying different
> ways to reduce the slow response to window move/resize I
> realized that the problem could be reduced by putting a limit to the
> frequency of moving and resizing windows. I found 50Hz to be a proper
> frequency for window moving on my system, but a slower frequency might be
> needed on slower systems. For window resize I use 25Hz.
>
> Some have argued that the real problem is that many applications are badly
> written. Properly written X application should compress expose and
> configure events. However many applications don't do this and this results
> in slow responsiveness of the system when moving and resizing windows.
>
> While my solution may not solve the real problem, it does help the
> situation with current applications. Also there is no reason to update
> windows position/size faster then 50Hz because the eye cannot percieve any
> significant difference between 50Hz and a higher frequency.
>
> I haven't tested the latest KDE and Gnome desktops so I don't know if they
> already do this.
I think you'll find if run X with the '-dumbSched' option, things may
behave a lot better without the rate limitation.
There is a problem with the XFree86 scheduling algorithm that tends
to cause window managers to starve applications. (Clients that get
mouse events and don't do much drawing get prioritized above clients
that don't get mouse events and do a lot of drawing)
Last time I talked to Keith about this, he had the idea that perhaps
when one client configures the window of another client, the priority
of the second client should be increased.
To really get things good, however, the window manager actually needs
to be able to tell when the client is done handling a particular
resize... this would require more substantial architectural changes.
Not to say that rate limitation isn't useful sometimes, but I think
it's basically just working around this scheduling bug.
Regards,
Owen
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
