2014-05-08 35 views
6

Używam GLFW, więc skonfiguruj okno z OpenGL. Ponieważ dopiero zacząłem uczyć się OpenGL i wszystkich rzeczy wokół niego, może to brzmieć jak głupie pytanie, ale dlaczego przykładowy program GLFW używa prawie 100% procesora, kiedy okno nie jest aktywnie wyświetlane (zminimalizowane lub ukryte przez inne okno)?Wysokie użycie procesora, gdy okno GLFW/OpenGL nie jest widoczne

Oto exmaple GLFW używam go na Mac OS z Xcode:

#include <GLFW/glfw3.h> 
int main(void) 
{ 
    GLFWwindow* window; 

    if (!glfwInit()) /* Initialize the library */ 
     return -1; 

/* Create a windowed mode window and its OpenGL context */ 
    window = glfwCreateWindow(640, 480, "Hello World", NULL, NULL); 
    if (!window) 
    { 
     glfwTerminate(); 
     return -1; 
    } 

/* Make the window's context current */ 
    glfwMakeContextCurrent(window); 

/* Loop until the user closes the window */ 
    while (!glfwWindowShouldClose(window)) 
    { 
     /* Render here */ 

     /* Swap front and back buffers */ 
     glfwSwapBuffers(window); 

     /* Poll for and process events */ 
     glfwPollEvents(); 
    } 

    glfwTerminate(); 
    return 0; 
} 
+0

Możesz rozważyć użycie VSYNC, przy okazji, które znacznie zmniejszy twój wątek rysowania. Zwykle robi się to z czymś bardziej inteligentnym niż spinlock, gdy rysujesz z dużą ilością klatek na sekundę, więc to skutecznie zmniejsza obciążenie procesora. Renderowanie nie jest wydajne *** *** szybciej *** niż możesz przesyłać klatki do monitora, chyba że masz super wymagające wymagania dotyczące czasu oczekiwania na wejście. –

+0

Dzięki za sugestię VYSNC, już robię glfwSwapInterval (1), myślę, że to wystarczy? –

+0

Tak, to wystarczy. Nie zauważyłem tego w twoim kodzie, więc założyłem, że korzystasz z domyślnego interwału wymiany. –

Odpowiedz

10

Twój pętli renderowanie jest wykonywany bez względu na to co mimimization stan okna jest.

Jeśli chcesz zatrzymać rendering, trzeba enhace logiki aplikacji trochę śledzić stan okno jest w. GLFW obsługuje zdefiniowany przez użytkownika wywołania zwrotnego dla takich rzeczy glfwSetWindowIconifyCallback() więc aplikacja może uzyskać zauważony, gdy okno jest zminimalizowane lub przywrócone. Możesz zdecydować o zatrzymaniu pętli renderowania i możesz użyć glfwWaitEvents(), aby poczekać, aż coś się stanie (np. Przywrócone okno) bez użycia całego dostępnego czasu procesora.

+0

Dzięki za odpowiedź, ponieważ moja pętla renderowania musi działać cały czas, z wyjątkiem sytuacji, gdy okno nie jest wyświetlane, glfwSetWindowIconifyCallback() jest dokładnie tym, czego szukałem. –

+1

Ale dlaczego tak się dzieje po zminimalizowaniu, a nie po wyświetleniu okna? Otrzymuję to samo zachowanie. I musi być logiczne wyjaśnienie i rozwiązanie tego problemu. – androidu

+3

W systemie OS X okno 'glfwSetWindowIconifyCallback' lub' glfwGetWindowAttrib (window, GLFW_VISIBLE) nie działa, gdy okno znajduje się za innym oknem, ale nie jest zminimalizowane. Mimo to użycie procesora wciąż rośnie. – whoKnows

2

Może zaczniesz coś robić?

Lub użyj "glfwWaitEvents();" zamiast "glfwPollEvents();" blokować, gdy nie ma nowych zdarzeń.

Dokumentacja wyjaśnić to na pierwszym etapie: http://www.glfw.org/docs/latest/quick.html

+0

Czy możesz dodać krótki przykład lub dodatkowe wyjaśnienie? –

1

NSOpenGLContext :: flushBuffer nie jest blokowanie, jeśli okno nie jest widoczne dla użytkownika (na przykład, istnieją inne okno przed nią). Ponieważ funkcja glfwSwapBuffers po prostu wywołuje tę funkcję, w takiej sytuacji staje się niezablokowana. Nie jestem pewien, jakie opcje musimy unikać zużywania 100% procesora w tym przypadku, z wyjątkiem korzystania z Core Video display link.

stąd: https://github.com/glfw/glfw/issues/680

OS X ignoruje interwał wymiany NSOpenGL gdy okno jest zasłonięte. Żaden inny system operacyjny tego nie robi. Zajmę się obejściem tego z linkiem do wyświetlania w pewnym momencie. Jeśli to nie zadziała, nie sądzę, że jest coś, co może zrobić GLFW.