2011-08-20 8 views
1

gtklext를 사용하여 gtk로 OpenGL을 사용하고 애니메이션을 수행 할 때 속도 저하 문제가 있습니다.많은 OpenGL 드로잉 영역 스와핑 버퍼 속도 저하 문제

기본적으로 GTK 앱에서 OpenGL을 사용하는 특정 디스플레이를 수행하는 응용 프로그램이 있습니다. 한 번에 많은 창을 열 수 있습니다 (그리고 특정 창에는 여러 개의 그리기 영역이있을 수 있습니다). 따라서 가능한 한 20-30 개의 OpenGL 그리기 영역을 화면에 표시 할 수 있습니다. 그림이 너무 무거워서 OpenGL이 그렇게 빠른 것은 아닙니다.

이 모든 디스플레이가 애니메이션을 적용하면 응용 프로그램의 속도가 느려질 수 있습니다. 문제에 대한 많은 연구 끝에 나는 문제를 일으키는 OpenGL에 대한 스왑 버퍼 호출을 결정했습니다. GTK로 그림을 그릴 때 위젯 노출의 모든 그림을 숨 깁니다. 그리기 영역 위젯에 gtk_widget_queue_draw를 호출하고 GTK가 해당 이벤트를 처리 할 때 그리기가 필요한 모든 위젯에 대해 연속적으로 expose 이벤트를 호출합니다. 이 문제는 드로잉이 끝나면 스왑 버퍼를 호출하여 화면에 실제 OpenGL을 그릴 필요가 있습니다 (이중 버퍼링 때문에). 모니터가 새로 고침 될 때까지이 호출이 차단 된 것 같습니다 (vysnc가 켜져 있기 때문에). 이것은 화면에 3 개의 드로잉 영역이 있다고 말할 때 문제가되지 않지만 톤이있을 때마다 스왑 버퍼 호출이 발생합니다.이 스왑 버퍼 호출이 호출되기 때문에 앱을 모두 차단하고 실제로 속도를 느리게합니다. 자신의 이벤트를 노출하고 아무 것도 동기화되지 않습니다.

내 질문에 너무 많은 차단되지 않도록 모든 스왑 버퍼 호출을 동기화하는 몇 가지 방법이 있습니다. vsync를 끄는 것은 (OS/OpenGL 구현이 구체적이기 때문에 그 자체로 불량 함) 속도 문제를 해결하지만 문제가 계속 발생합니다. GTK 공개 이벤트에서 swapbuffers를 수행해야하므로 다중 스레드가 도움이되는지 확신 할 수 없습니다. 그리기는 GTK와 동기화됩니다.

도움이 될 것입니다.

답변

1

20 개 이상의 창문이 있다면 무엇을 기대합니까? 각 화면은 화면 새로 고침과 동일한 타이밍으로 동기화됩니다. 그 시간 동안 각자는 많은 메모리 조작을해야 할 것입니다. 동시에. 물론 경기가 둔화 될 것입니다. 20 개 이상의 프로세서가 없다면, 그들은 다른 프로세서보다 한 줄 먼저 있어야 할 것입니다.

실제로 사용자에게 표시되는 GL 창의 수를 제한하는 것 외에는 할 수있는 일이 많지 않습니다.

+0

각 OpenGL 창이 하나의 삼각형 만 그립니다. SwapBuffers가 호출 된 스레드를 블로킹하는 V-Sync가 문제입니다. – datenwolf

0

이 문제를 해결하기위한 일반적인 접근 방법은 각 OpenGL 컨텍스트마다 스왑 할 자체 스레드를 사용하는 것입니다.

그러나 OpenGL 개발자는 "조정 된 스왑"또는 이와 비슷한 것을 소개하는 새로운 확장을 도입 할 수 있습니다. 몇 가지 동기화 확장이 있습니다. 가장 많이 쓰이는 부분은 http://www.opengl.org/registry/specs/OML/glx_sync_control.txt