At first I was thinking "What a high quality troll. Good job.". But since it appears to be somewhat serious I suggest that if you really want a "better" XFree86, you should define, document, and perform the appropriate benchmark tests. Then the XFree developers are very likely to make improvements that improve that benchmark.
These words have meanings: Define - The benchmark should be structured so that it really represents a test of X, not some application. If possible, it should reflect an understanding of the X environment so that individual contributing factors can be isolated and improved. Document - This means it should be reasonable for some third party to reproduce your results and perform these benchmarks without needing any further advice. Peform - Tell us what it does today (in your environment) and what you think the should be achievable. >From some of the later discussion I started to wonder whether the following optimization might be appropriate as an X option or extension. At present, XMotionEvents are sent at a fairly high rate when there is rapid mouse motion. I have measured XMotionEvents in excess of 100 per second. A well written application will collapse multiple XMotionEvents into a single motion. This is a routine optimization that is part of every programming example that I have read. I experienced, found, and fixed one path through the WindowMaker window manager where the combining was not being done. This was a bug in WindowMaker that really looked like an X bug. You had to get just the right configuration because almost all of the paths through WindowMaker were combining events. I happened to have the one that did not. It showed up first with X 4.0 because 4.0 was much faster than 3.5. Perhaps there would be value to a motion rate limiting option in the X server. This is not merely covering up for flawed applications. In the current environment, a fast application can respond to the XMotionEvent faster than the events are sent. So the fast application is performing the cycle of read an event, update the screen, and returning to read another event several times per screen refresh. This is waste motion and interferes with scheduler logic. It would make sense to specify to the X server that it should combine motion events for 10-20 milliseconds before sending another motion event. This avoids all the scheduling and messaging traffic during that invisible interval. But what will this break? I know that making the rate limit too long will definitely make the system very jerky and erratic. Does this break other aspects of the system? I think that this has to be done at the server level rather than at any lower level (like window), so I want to be fairly sure that it will not cause problems. The implementation will have some difficult spots, like making sure that the final event does make it out to the client when the time delay expires. R Horn _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
