SFML在非主线程中无法正常轮询事件的问题求助

Let's break down why your window is freezing and how to fix it—this is a common pitfall tied to platform-specific GUI threading rules, not just an SFML quirk.

The Root Cause #

On Windows, window events and message handling must run in the thread that created the window. SFML's pollEvent() and waitEvent() under the hood interact with the Windows message queue, which is tightly bound to the thread that initialized the window. When you run your event loop in a secondary thread, even with mutex locks and setActive() calls, the Windows OS doesn't see the main thread processing window messages. After a short timeout, it marks the window as "Not Responding" because the thread that owns the window isn't tending to its message queue.

Your current setup violates this platform constraint—SFML can't work around this Windows-specific rule, no matter how you lock or activate the window across threads.

The Solution #

Restructure your code to split responsibilities cleanly:

• The main thread takes exclusive care of window creation, event handling, and rendering.
• Secondary threads handle only background logic (like computations, asset loading, or state updates) and communicate with the main thread via thread-safe data structures if needed.

Revised Code Example #

Here's how to adjust your setup to comply with Windows' threading rules:

#include <SFML/Graphics.hpp>
#include <thread>
#include <mutex>
#include <queue>

std::mutex sharedDataMutex;
std::queue<int> backgroundUpdates; // Example shared data from worker thread
bool isAppRunning = true;

// Worker thread: handles background tasks, no window operations whatsoever
void backgroundWorker() {
    while (isAppRunning) {
        // Do your off-window work here (calculations, file I/O, etc.)
        std::lock_guard<std::mutex> lock(sharedDataMutex);
        backgroundUpdates.push(1); // Send data/updates to main thread
        std::this_thread::sleep_for(std::chrono::milliseconds(100));
    }
}

int main() {
    // Window is created in the main thread (critical for Windows)
    sf::RenderWindow window(sf::VideoMode(800, 600), "SFML Thread Fix");
    std::thread worker(backgroundWorker);

    while (window.isOpen()) {
        sf::Event event;
        // Event loop stays strictly in the main thread
        while (window.pollEvent(event)) {
            if (event.type == sf::Event::Closed) {
                window.close();
                isAppRunning = false; // Signal worker thread to exit
            }
            // Handle other events (key presses, mouse input, etc.) here
        }

        // Process updates from the worker thread (thread-safe)
        std::lock_guard<std::mutex> lock(sharedDataMutex);
        while (!backgroundUpdates.empty()) {
            int update = backgroundUpdates.front();
            backgroundUpdates.pop();
            // Use the update in your main thread logic/rendering
        }

        // Rendering also stays in the main thread
        window.clear(sf::Color::White);
        // Draw your game/UI elements here
        window.display();
    }

    worker.join();
    return 0;
}

Key Notes #

• You won't need setActive(true/false) in this setup unless you're doing off-screen rendering in a secondary thread (but even then, event handling must stay in the main thread).
• Mutex locks are only for protecting shared data between threads—window operations (event handling, rendering, close()) should never be touched by secondary threads.
• If you prefer waitEvent() over pollEvent(), that's fine for the main thread, but it will block until an event occurs. Just make sure your background work doesn't depend on the main thread being unblocked constantly.

This approach will immediately resolve the "Not Responding" issue on Windows, as the main thread is now properly tending to the window's message queue as the OS expects.

内容的提问来源于stack exchange，提问作者AnnikGet