[fixed in 1.8] Overuse of XQueryPointer (linux)

[hendu]

CursorControl->get[Relative]Position make a roundtrip to X each time.

The problem is that depending on X's load, it can take a while to process - I have measured times from 10 us to 30 ms. The average is sub-1ms, but the occasional spike can be felt.

The problem is aggravated by several calls in the FPS cam without even attempting to cache, such as:

Code: Select all

CSceneNodeAnimatorCameraFPS.cpp:                core::vector2d<u32> mousepos(u32(CursorControl->getPosition().X), u32(CursorControl->getPosition().Y));

I'm not sure whether skipping the XQueryPointer call altogether and using the coordinates from the last mouse move event would be usable. Maybe not in low fps.

Perhaps cache with a time delta? If the last call was > 10ms ago, only then do another?

[hendu]

It appears SDL uses the position from the last mouse event:

http://hg.libsdl.org/SDL/file/36f33f295 ... nts.c#l518

[hendu]

Benchmark, if you're interested:

Code: Select all

#include <stdio.h>
#include <X11/Xlib.h>
#include <sys/time.h>
 
#define count 1000
 
int main() {
 
        Display *d = XOpenDisplay(NULL);
        if(!d) return 1;
 
        Window root = DefaultRootWindow(d), w;
        int x, y, tmpi, i;
        unsigned int utmp, min = 100000, max = 0, avg = 0;
        struct timeval one, two;
 
        for (i = 0; i < count; i++) {
 
                gettimeofday(&one, NULL);
 
                XQueryPointer(d, root, &w, &w,
                                &x, &y, &tmpi, &tmpi, &utmp);
 
                gettimeofday(&two, NULL);
 
                utmp = (two.tv_sec - one.tv_sec) * 1000000;
                utmp += (two.tv_usec - one.tv_usec);
 
                avg += utmp;
                if (min > utmp) min = utmp;
                if (max < utmp) max = utmp;
        }
 
        avg /= count;
 
        printf("The call took (%u, %u, %u) (min, avg, max) usec\n",
                min, avg, max);
 
        XCloseDisplay(d);
        return 0;
}

[CuteAlien]

Interesting, didn't know. But not sure if just using last mouseevent is a solution - people are not forced to call device->run(), although they probably do that in 99.999% of all cases. Maybe adding a "cache" state to CursorControl would be a solution?

[hendu]

Yeah, the first ->run call can turn that toggle on, and everything works for everybody. With it on, use the mouse events only, with off query just as now - did I get you right?

BTW, could you fix the worst cases of the FPS cam queries Even if the call were instant, those are still unnecessary function calls.


[background: damn were I surprised when lag in my physics turned out to be from mouse positions ]

[CuteAlien]

Hm, I'm probably not here this weekend (some kind of yearly repeated festivities happening next 2 days). Plus some other bugs on waiting list *sigh* - but will try getting to it.

[hendu]

Oh, those tribal acts? Disturbing I know. No rush.

[hendu]

Patch posted:
http://sourceforge.net/tracker/?func=de ... tid=540678

I've given it light testing, no noticable lag in gui in example 09.

[hendu]

Damn, it's a bit jerky in 3d movement. Scratch this approach then.

[CuteAlien]

Ah good I spend so long on other bugs yesterday ;-)
Might also be interesting to check how this behaves compared to the old version (and maybe compared to Windows version) when the application Window is not active.

[hendu]

How's an inactive window related?

[CuteAlien]

It probably gets no longer XEvents (guessing here, I'm on the wrong OS right now). Not sure right now if someone might still want to get the mouse-coordinates in that case, but if so then we probably have to update them in that case using the old method.

[hendu]

I tried another way, limiting the call to once per frame. This does not fix the bug, but makes it occur less often. Has no downsides that I can see, 3d movement is smooth.

Patch at the same url.

[hendu]

Bringing this up on the Xorg ML, surprisingly it brought up an issue in the X server's scheduling algorithm.

So for Irrlicht, please apply the patch to limit the calls to one per frame. To 1.7 too if possible, it's a bug fix since it eases some skipping.

For apps based on irrlicht, on systems with older X servers, just recommend the old trick of "start a separate X server for gaming (or at least close as many other apps as possible)" in your README.

[CuteAlien]

Hm, 1.7 is risky (I really don't want to accidentally break the mouse-cursor for existing applications...), so I planned to add it to trunk, I'll think about that once more. I'll test it as soon as possible, but I still have to fix 3 other bugs for 1.7 - I hope I can finish those on Monday (usually my Irrlicht day).