Slow XQueryPointer?

[Adam Jackson]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg-devel/attachments/20120126/962ea7e1/attachment.pgp>