I’ve noticed after enabling the Editor setting to display frame rate and memory usage, during intense loading periods or heavy stress tests when the Editor is running very slowly, the display never goes below 8 FPS. I tracked this down to a clamp in FSlateApplication::TickTime, with the comment “Handle large quantums”. It seems like this was added quite a while ago, along with some changes to split up Slate’s tick into phases to play nicer with replay recording where inputs needed to be processed before doing widget logic or something.
Besides being a “lie” about the current perf, which is not a huge deal because that setting is off by default anyway, there are other systems that can and do rely on FSlateApplication to know how much time has passed since their last tick. The comment on the function says “Returns the real time delta since Slate last ticked widgets”, which may not be true. There is also GetAverageDeltaTimeForResponsiveness(), which has its own clamping, but on top of this already clamped value. And the place where that is calculated, after the original clamp, says “Update average time between ticks. This is used to monitor how responsive the application “feels”. Note that we calculate this before we apply the max quantum clamping below, because we want to store the actual frame rate, even if it is very low.” This all points me to the possibility that the clamp to 8 FPS is either something of an accident, or if intent changed but the comments didn’t.
For what it’s worth, I commented out the clamp to 8 a few weeks ago, and nothing has exploded, so I’ve just been enjoying the more flexible perf measurement. But I wanted to ask, in case there was a good reason for the clamp and I should not do that. Thanks for any insight.
Hey!
This is indeed super old code so it’s tough to say the exact thought, though the clamping is likely meant to prevent unwanted behavior when the delta gets extremely large since many things may be multiplying by this value. I leave the editor performance stats on as well and hadn’t noticed, though I also disable “Use Less CPU when in Background” since a slow editor feels bad in a multi-monitor context. You could try leaving the engine on a breakpoint over a weekend to see if anything strange happens when you resume, but it’s likely just an abundance of caution since we can’t be sure how delta time will be used throughout the engine.
Best,
Cody
Hey Cody,
I gave it a shot and left my Editor on a breakpoint last night, then resumed this morning. Everything went just fine, with the perf stats in the Editor of course starting at 0 but climbing back up to normal over a second or two. Just got this one amusing log line:
LogShaderCompilers: Display: Distributed compilation controller didn’t receive a completed task in 56769.631270 seconds!
I will likely move forward with submitting this code at our studio, and obviously it’s low priority, but I’d encourage you guys to re-evaluate as well. It may be worth mentioning that we do not use Slate for game UI, so this won’t affect our runtime at all. If this could affect that, it would be worth someone checking there too, but it wouldn’t be something I can look into. 
Thanks,
Matt
Hi,
I’ll bring it up with the Slate team, maybe we can reevaluate. As a note, Slate is responsible for the underpinnings of the application window and input handling, so even if Slate isn’t used for any in-game UI, there’s still some chance that changes to SlateApp could affect a built project. If you wanted to be safe you could always lower the clamp to something like 1fps so it still clamps egregious cases, with the added benefit of being able to test the worst-case scenario more thoroughly with t.maxfps 1.
Best,
Cody