0

XCB をバックエンド (もちろん GLX の場合は xlib) としていくつかの基本的な OpenGL アプリケーションを作成しました。作成したすべてのテストで、マウスをウィンドウ上に移動すると、すべての入力が一種の「バッファリング」され、応答するだけです。一定期間後のイベント (入力の数によって異なります)。

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

3 に答える 3

0

あなたの例の外観から、多くのイベントが周りにない場合 (poll_for_events は NULL を返し続ける)、アプリケーションは非常にタイトなループで実行され、多くの不要な作業が行われ、システム全体が遅くなる可能性があります。

CPU使用率などは確認しましたか？新しいデザインで xcb_wait_for_event に切り替えたと仮定しても安全でしょうか?

于 2013-10-28T06:15:07.017 に答える
0

なぜラグが発生しているのかわからなかったので、イベント ポーリング関数を呼び出し、別のスレッドでユーザー入力を更新し (xcb に感謝)、すべてのレンダリングをメイン スレッドで行いました。これでスムーズに動作し、入力ラグがなくなりました。シングルスレッド設計でなぜ遅れていたのかを理解できればいいのですが:/

于 2013-10-28T05:05:54.383 に答える