On Thu, 2012-01-26 at 19:34 +0200, Lauri Kasanen wrote: > Hi ajax > > Thanks for taking the time to look into this. > > Trying -schedInterval 5 had slight improvement - the skips weren't as > high, the highest was 7ms. But the skips still happen about just as > often.
That's about what I'd expect. The worst-case latency with the current algorithm is linear [1] on the number of clients you're contending with, so you're still going to see latencies greater than the timeslice if you have more than one other app to compete with. > This sounds good. Could this make it to the next xserver release? Well, we can try. Certainly tuning the defaults would be an improvement even if we don't fix the algorithm. I don't know if I'll have a better algorithm for 1.12.0 but it should be easy to backport whenever it gets written. > Also, even when this is fixed, there's going to be many linux systems > without it for a year or two. Would there be any workaround for > affected systems my app could do? Simplest thing (although kind of hideous) might be to launch another thread with its own Display connection and only ever run XQueryPointer from that, save the coordinates in some shared variable protected by a mutex, and read from that in the main thread. Or in a separate process over a pipe, if you don't like threads. I don't really know what you need the result for, though, so I don't know if that's a viable technique for you. [1] - Not actually sure it's not worse than that, tbh. I suspect there's ways you could end up starved forever with no more than two other clients (and without even going into the sync extension's priority levels). - ajax
signature.asc
Description: This is a digitally signed message part
_______________________________________________ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
