0

I have written some basic OpenGL applications with XCB as the backend(xlib for GLX, of course) and in every test I have written when I move my mouse over the window it causes all input to get sort of "buffered" and only responds to the events after a period of time(varies depending on how many inputs).

I'm calling xcb_poll_events and getting the event information that way then loading it into a custom event class, but this was never slow on my old xlib implementation.

What could be causing this lag?

The event polling:

Event_c system_class::poll_for_event(){
    Event_c temp;

    xcb_generic_event_t *event;
    event = xcb_poll_for_event(this->connection_xcb);

    if(!event)
        return temp;

    switch(event->response_type){
        handle events...
    }

    free(event);
    return temp;
}

and the event loop in the test app:

int main(int argc, char *argv[]){

    init stuff...

    system_class app;
    window_class window;

    Event_c event;
    while(running){
        event = app.poll_for_event();
        if(event.detail){
            handle user input...
        }

        window.swap_buffers(); // just calls glXSwapBuffers
    }

    return 0;
}
RamblingMad
  • 5,332
  • 2
  • 24
  • 48

3 Answers3

2

Your problem is, that you are calling glXSwapBuffers between two calls of xcb_poll_for_event. Therefore you only can handle one message per screen refresh.

Apart from your multithreading solution you could simply process events until xcb_poll_for_event would return zero. When you are finished with handling all pending events, you could return to rendering.

BaronBoese
  • 36
  • 2
0

Couldn't figure out why it was causing lag, so I called my event polling function and updated the user input in a separate thread (thank you xcb) and did all of my rendering in the main thread. Now it runs smooth and has no input lag. I wish I could figure out why it was lagging in the single threaded design though :/

RamblingMad
  • 5,332
  • 2
  • 24
  • 48
0

From the look of your example, the application would be running in a very tight loop if there are no that many events around (poll_for_events will keep returning NULLs) doing a lot of unnecessary work and possibly making the whole system to go sluggish.

Have you checked the CPU utilization and such? Would it be safe to assume that in your new design you switched to xcb_wait_for_event?

oakad
  • 6,945
  • 1
  • 22
  • 31
  • The whole system was fine, and the app was running smooth as hell, the input was the only thing that lagged :/ Yeah, that would be a safe bet ;) no point in running a loop too many times. – RamblingMad Oct 28 '13 at 12:15
  • The only other things which may influence the behavior of the xcb_poll_for_event are the queue mutex and recv() system call. One of those, when accessed too often, is causing your problem (as evidenced here: http://cgit.freedesktop.org/xcb/libxcb/tree/src/xcb_in.c). – oakad Oct 29 '13 at 00:57