pollEvent slows down game loop

[asdftest]

Hi,

I'm having trouble with SFML's pollEvent on my system. When I'm moving my mouse around, the pollEvent-while-loop takes longer to compute (I can even stretch the processing time of the loop arbitrary long by continuously moving the mouse). I suspect that the event queue gathers more elements than can be processed.

Is there a fix for this problem? This problem only occurs on my laptop (specs below). However, I'm able to play other (more demanding) games with ease and therefore think this empty (!) while-loop shouldn't be a problem at all.

#include <SFML/Graphics.hpp>
#include <chrono>
#include <iostream>

int main(int argc, char** argv)
{
   sf::RenderWindow window(sf::VideoMode(300, 300, 32), "Hello");

   while (window.isOpen()) {
      auto start = std::chrono::system_clock::now();

      sf::Event event;
      while (window.pollEvent(event)) {
         if (event.type == sf::Event::Closed) {
            window.close();
         }
      }

      window.clear();
      window.display();

      auto end = std::chrono::system_clock::now();
      std::chrono::duration<double, std::milli> duration = end - start;
      std::cout << duration.count() << std::endl;
   }

   return 0;
}
 

Output:

23.2476
37.9425
31.6247
38.5042
44.0676
57.304
31.7052
24.3704
39.865
28.6723
146.977 <-- short mouse movement
28.2425
67.8935
1059.84 <-- heavy mouse movement
2356.55 <-- heavy mouse movement
 

My specs:

• SFML 2.1
• OS: Debian 8.11 jessie
• CPU: Intel Core i5-2450M CPU @ 3.1GHz
• GPU: GeForce GT 540M
• RAM: 7856MB

[Hapax]

I would say to start with that the timing isn't particularly accurate due to the constant output stream. Maybe try storing the values and output later, outside the loop.

That said, a 1-2 second delay for just moving the mouse seems overly slow.

Are you building for 32-bit or 64-bit? Is there a difference between debug and release builds?

Have you tried it with the latest SFML version? This may have already been fixed.

[eXpl0it3r]

If your mouse generates thousands of events for moving it, you may want to check the driver.

[asdftest]

I would say to start with that the timing isn't particularly accurate due to the constant output stream. Maybe try storing the values and output later, outside the loop.

I changed the code to save the timing of the event loop and the game loop in std::vectors.

        std::vector<std::chrono::duration<double, std::milli>> outerLoop;
        std::vector<std::chrono::duration<double, std::milli>> eventLoop;

        while (window.isOpen()) {
                auto start = std::chrono::system_clock::now();

                sf::Event event;
                while (window.pollEvent(event)) {
                        if (event.type == sf::Event::Closed) {
                                window.close();
                        }
                }

                auto eventLoopEnd = std::chrono::system_clock::now();
                std::chrono::duration<double, std::milli> eventLoopDuration = eventLoopEnd - start;
                eventLoop.push_back(eventLoopDuration);

                window.clear();
                window.display();

                auto outerLoopEnd = std::chrono::system_clock::now();
                std::chrono::duration<double, std::milli> duration = outerLoopEnd - start;
                outerLoop.push_back(duration);
        }

        for (int i = 0; i < outerLoop.size(); i++) {
                std::cout << eventLoop[i].count() << "/" << outerLoop[i].count() << std::endl;
        }
 

The result looks quite similar (time for pollEvent() / time for whole loop):

74.993/77.4701
37.7147/38.7078
61.1917/61.7517
25.2882/26.0204
27.2782/27.9917
50.2894/50.8609
6456.38/6457.17 <--
31.2891/31.9878
23.2266/23.7363
39.5351/40.2131
27.3012/27.9531
44.4714/45.216
30.5088/31.2549
22.9023/23.4643
36.3201/37.0252
46.4025/47.3068
27.0558/27.8235
51.2929/51.8331
31.0223/31.0261
 

Are you building for 32-bit or 64-bit? Is there a difference between debug and release builds?

I'm building for 64-bit on release. The debug version suffers from the same performance hit.

Have you tried it with the latest SFML version? This may have already been fixed.

Unfortunately, I was (as of yet) unable to install the newest version

If your mouse generates thousands of events for moving it, you may want to check the driver.

I measured how long the while loops takes and how many MouseMoved-Events are processed and got about 60-80 MouseMoveEvents per second.

[eXpl0it3r]

Time to start a profiler and find out what driver is eating all the time.

But make sure to first test the latest version.