Inicialmente, meu código configurou o ambiente SDL e atualizou o contexto OpenGL, sem executar nenhum processamento SDL_Event. Isso faz com que a janela, desde que aberta, apareça no Windows como sem resposta. A janela pisca um pouco. A barra de título seria anexada a "(Não está respondendo)" e, ao clicar dentro da janela, ela fica acinzentada, pois o Windows faz isso por padrão em janelas não responsivas. No entanto, nesse estado (mesmo quando e depois de acinzentado), a tela do OpenGL continua sendo atualizada e animada, e aqui está o kicker, ele ainda o faznquanto a janela estiver sendo arrasta. Claramente, neste caso, o aplicativo não está manipulando eventos das janelas corretamente, fazendo com que as janelas pensem que estão em um estado interrompido. Mas há evidências claras de que o opengl continua a renderiza

gora, eu faço uma única modificação no código, que são essas três linhas colocadas em um local apropriado dentro do loop (que também faz o OpenGL desenhar

SDL_Event event;
if (SDL_PollEvent(&event) && event.type == SDL_QUIT)
    break;

Tudo o que isso está fazendo é liberar a fila de mensagens usando SD

Agora, o comportamento é que o Windows não pensa mais em "Não está respondendo" e não fica acinzentado. Sem cintilação. Tudo parece correr bem. Mas quando clico e arrasto a barra de título para arrastar a janela, a renderização é bloqueada. Não o depurei para ter certeza, mas suspeito que o SDL_PollEvent bloqueie a duração do arrasto da janel

Existe uma maneira de contornar isso? Isso é interessante porque parte do comportamento exibido por falha em manipular eventos é a prova de que o que eu quero é possível em teori

Update: Encontrei este tópico:http: //www.gamedev.net/topic/488074-win32-message-pump-and-opengl---rendering-pauses- while-draggingresizing

O veredicto parece ser que se resume a certas escolhas que a Microsoft fez para nós ... Basicamente, ele fica preso emDefWindowProc() até o mouse ser liberado. Seria muito confuso hackear uma correção para isso e talvez eu consiga fazer uma solução alternativa renderizando em outro thread. Mas nem quero começar a pensar em manipular um contexto OpenGL a partir de vários threads, se isso é algo possíve