Имейте в виду, что вы ДОЛЖНЫ создать окно в потоке, которое выполняет обработку событий. Если нет, это не сработает. Вы можете создать окно в вашем потоке обработки событий, а затем передать этот указатель окна вашему потоку рендеринга.
ла мой код настроил среду SDL и приступил к обновлению контекста OpenGL, не выполняя никакой обработки SDL_Event. Это приводит к тому, что окно, пока оно было открыто, кажется Windows не отвечающим. Окно немного мерцает. К заголовку будет добавлено «(не отвечает)», и после щелчка внутри окна оно станет серым, поскольку Windows делает это по умолчанию на неотвечающих окнах. Однако в этом состоянии (даже если он становится серым), дисплей OpenGL продолжает обновлять и анимировать, а вот кикер, он даже делает этово время перетаскивания окна, Очевидно, что в этом случае приложение не обрабатывает события из окон правильно, заставляя окна думать, что оно находится в зависшем состоянии. Но есть явное свидетельство того, что opengl продолжает оказывать.
Теперь я делаю одну единственную модификацию кода, которая состоит из трех строк, помещенных в соответствующем месте внутри цикла (который также рисует OpenGL):
SDL_Event event;
if (SDL_PollEvent(&event) && event.type == SDL_QUIT)
break;
Все, что это делает, это очищает очередь сообщений с помощью SDL.
Теперь поведение таково, что Windows больше не думает, что она «не отвечает», и она не выделяется серым цветом. Нет мерцания. Кажется, все идет гладко. Но как только я перетащил строку заголовка, чтобы перетащить окно, рендеринг блокируется. Я не отладил это, чтобы быть уверенным, но я подозреваю, что SDL_PollEvent блокирует на время перетаскивания окна.
Это можно обойти? Это интересно, потому что часть поведения, демонстрируемаяне в состоянии обрабатывать события доказательство того, что то, что я хочу, возможно в теории.
Обновление: я нашел эту тему:http://www.gamedev.net/topic/488074-win32-message-pump-and-opengl---rendering-pauses-while-draggingresizing/
Похоже, что вердикт сводится к определенному выбору, который Microsoft сделал для нас ... Он в основном застрял вDefWindowProc() пока мышь не отпущена. Было бы очень беспорядочно взломать исправление для этого, и я мог бы обойтись путем рендеринга в другом потоке. Но я даже не хочу думать о манипулировании контекстом OpenGL из нескольких потоков, если это вообще возможно.