движение мыши xcb вызывает задержку ввода

0

Я написал некоторые базовые приложения OpenGL с XCB в качестве бэкэнд (xlib для GLX, конечно), и в каждом тесте, которое я написал, когда я двигаю мышью над окном, он заставляет все входные данные получать "буферизацию" и реагирует только на события через определенный промежуток времени (варьируется в зависимости от количества входов).

Я вызываю xcb_poll_events и получаю информацию о событиях таким образом, а затем загружаю его в пользовательский класс событий, но это не было медленным в моей старой реализации xlib.

Что может вызвать это отставание?

Опрос событий:

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;
}

и цикл событий в тестовом приложении:

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;
}
Теги:
xlib
xcb
glx

3 ответа

1
Лучший ответ

Ваша проблема в том, что вы вызываете glXSwapBuffers между двумя вызовами xcb_poll_for_event. Поэтому вы можете обрабатывать только одно сообщение для обновления экрана.

Помимо многопоточного решения, вы можете просто обрабатывать события, пока xcb_poll_for_event не вернет нуль. Когда вы закончите обработку всех ожидающих событий, вы можете вернуться к рендерингу.

  • 0
    Спасибо, да, я понимаю это сейчас, но этот вопрос казался архаичным, и я не знал, стоит ли его обновлять: L
0

С точки зрения вашего примера приложение будет работать в очень узком цикле, если таких событий не будет (poll_for_events будут продолжать возвращать NULL), делая много ненужной работы и, возможно, делает всю систему вялой.

Вы проверили использование ЦП и т.д.? Можно ли предположить, что в новом дизайне вы переключились на xcb_wait_for_event?

  • 0
    Вся система была в порядке, и приложение работало безупречно, черт возьми, единственное, что отставало от ввода: / Да, это была бы безопасная ставка;) Нет смысла запускать цикл слишком много раз.
  • 0
    Единственное, что может повлиять на поведение xcb_poll_for_event, это системный вызов queue mutex и recv (). Один из них, когда к нему обращаются слишком часто, вызывает вашу проблему (как показано здесь: cgit.freedesktop.org/xcb/libxcb/tree/src/xcb_in.c ).
0

Не могу понять, почему это вызвало лаг, поэтому я назвал функцию опроса событий и обновил пользовательский ввод в отдельном потоке (спасибо xcb) и сделал весь мой рендеринг в основном потоке. Теперь он работает ровно и не имеет входного запаздывания. Мне жаль, что я не мог понять, почему он отставал в однопоточном проекте:/

Ещё вопросы

Сообщество Overcoder
Наверх
Меню