On 16 Jul, David Dawes wrote: > On Mon, Jul 15, 2002 at 01:11:17AM +0200, Lukas Molzberger wrote:
An excellent troll. Well crafted to generate lots of entertainment for the silent audience. But since perhaps there was a genuine attempt to be helpful >>1. XFree is far too slow. Provide a benchmark. A good quality benchmark is appreciated by the developers. You can be confident that they will make changes that result in the benchmark running better. A good benchmark is also much easier that a whole new window system. By good, I mean: 1) Well documented. It should come complete with sufficient instructions to permit anyone to use it and duplicate your results. 2) Well designed. It should accurately reflect the behavior of the more complex real world systems. If improving functions A, B, and C makes the benchmark run well, then that should make the real world systems run well. 3) Portable. XFree is operating system and CPU independent. The benchmark and its improvements must also be portable. >>2. What is presented on the screen should always be consistent (i.e. no >>flickering). >From the other discussions this could be related to motion update event rates. There is a problem with the current design. The event rate for motion updates is hardware dependent. I know that when I transitioned from 3.5 to 4.0 I had problems with Windowmaker. These turned out to be the result of a bug in Windowmaker (which I fixed) and the update rate. My hardware was generating updates at about 200 per second. So even after I fixed the bug, the window motion logic would redraw a moving window 200 times per second. This is silly on a system with a refresh rate of 72 frames per second. It probably also confused the scheduling logic in addition to wasting resources. There are only partial fixes for this. For the really common mouse hardware there are some adjustments that can be made. The IMPS/2 hardware can be set at 80, 100, or 200. The present default for X is a setting of 80. That is about right for most purposes. Is it worthwhile to have a software controlled rate limiter inside the X server? This would deal with hardware that lacks a rate limiter and change the other tradeoffs. You might get better performance and features by setting the hardware at 200 per second and dropping the server rate to match the frame rate. I think I know what changes are needed if this is a good idea. I'm not particularly motivated at present because the hardware rate limiter is close enough for all of my hardware. (BTW, my windows machine tears when moving windows, but it's a slow machine.) R Horn _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
