# Fullscreen FPS slowdown in Linux [closed]

I've got a homemade game engine that supports both Windows and Linux using Win32 and Xlib, respectively. By default, the engine will create the window and then switch it into fullscreen mode. When running in Linux, the main game loop updates with a very low framerate (2-7 FPS) that slowly keeps ticking downwards. If I alt-tab out and then alt-tab back in, the game will shoot up to and stay at a consistent 60 FPS.

Since my time since last tick (dt) keeps increasing during this time, my thought is it has something to do with the game not being properly registered as "fullscreen" when it's initially opened, leading the CPU scheduler to not give it full priority. That being said, that's entirely speculation. Does anyone have any idea what the cause of this could be? I can provide code samples if requested.

System info:
Linux Mint 17 Cinnamon 64-bit
Intel Core i7 @ 3.40GHz x 4
8GB DDR3 RAM
Nvidia GeForce GTX 680 with proprietary driver

Edit
My update loop is as follows:

while (gameIsRunning) {
auto currentTime = std::chrono::steady_clock::now();
auto dt = std::chrono::duration<float>{currentTime - lastFrame};
if (dt >= engine->getFrameInterval()) { // getFrameInterval returns (1 / the target framerate) in seconds; in this case, 1/60s
if (dt >= engine->getFrameInterval() * 2) {
lastFrame = currentTime;
} else {
lastFrame += std::chrono::duration_cast<decltype(currentTime - lastFrame)>(engine->getFrameInterval());
}

// input, update, draw...
}
}


After fooling around with it a bit, this creates a situation where the framerate will jump back up to 60FPS, tick down until it hits about 30FPS, and then jump back up to near 60FPS before ticking down again.

## closed as off-topic by bummzack, MrCranky, Josh♦Jul 21 '14 at 16:11

This question appears to be off-topic. The users who voted to close gave this specific reason:

• "Questions about debugging a problem in your project must present a concise selection of code and context so as to allow a reader to diagnose the issue without needing to read all of your code or to engage in extensive back-and-forth dialog. For more information, see this meta thread." – bummzack, Josh
If this question can be reworded to fit the rules in the help center, please edit the question.

• Your problem is in the second code file, line 432, right after the +. If that isn't accurate enough for you, think about it and then post some code. :) – Mario Jul 21 '14 at 7:43
• @Mario I'm not necessarily looking for specific code issues (although it's almost definitely going to be something like that that's causing this). I've run a profiler on my code and there are no functions that take an inordinate amount of time (more than one frame's worth added together). I'm trying to understand if there's something at a system level that might be causing my game to run slower, especially given that alt-tab out and back in causes a noticeable and measurable FPS increase. – Kazzatso Jul 21 '14 at 16:10

## 1 Answer

"that slowly keeps ticking downwards" - this is your bottleneck. When doing a game engine with a standard update and render loop, you have to be careful that the update does not take too much performance, or else you will enter in a bottleneck. From what I can understand, your update loop looks a bit like this one:

dt += (timeNow - timeThen) * FPS / 1000; // In miliseconds
while (dt >= 1) {
// Update stuff
dt -= 1;
}


If you are doing something like this and dt starts getting out of hand (that is, higher than 10), you want to have some sort of mechanism to stop that. The simplest one is to change the line

dt -= 1;


by

dt = 0;


This will fix all problems but will be less accurate (though the accuracy loss is not significant). Another option is to add this after this line:

dt -= 1;
if (dt > 4) {
dt = 0
}


This will add a check whether or not the loop is going out of control and will bottleneck the entire engine.

• Edited my question to add my update loop code. It's already doing something very similar to what you suggested. – Kazzatso Jul 21 '14 at 16:03