Godot: Stutter/Jitter and screen freezing in a simple 2D project

[diiiiiiiii]

Godot version:
Godot 3.0.6

OS/device including version:
MacOS 10.14.1
MacBook (Retina, 12-inch, 2017)
1.2 GHz Intel Core m3
8 GB 1867 MHz LPDDR3
Intel HD Graphics 615 1536 MB
(Also reproduced on multiple devices including PC and exported game on mobile and PC.)

Issue description:
Any object that is moving seems to periodically stutter or jitter accompanied by screen freezing in a 2D project.
And it seems to happen more frequently on devices with low processing powers or non-Windows devices.

Steps to reproduce:
Create a new project with a KinematicBody2D or an AnimatedSprite or a RidiBody2D and modify position with move_and_slide() or set_global_position() or apply_impulse() after adding a Camera2D as a child node.(But it still happens even without the Camera2D.)

Minimal reproduction project:
3.1 Beta 2
~Godot_Jitter.zip~
Improved Version by @Ploppy3

---

KinematicBody2D, _physics_process(), move_and_slide()

https://youtu.be/78S95yugRDk

extends KinematicBody2D
const SPEED = 75
var motion = Vector2()

func _physics_process(delta):
    if Input.is_action_pressed('ui_right'): motion.x = SPEED
    elif Input.is_action_pressed('ui_left'): motion.x = -SPEED
    else: motion.x = 0
    motion = move_and_slide(motion, Vector2(0, -1))
    print(delta, position)

---

AnimatedSprite, _physics_process(), set_global_position()

https://youtu.be/gdc6NOoWG4E

extends AnimatedSprite
const SPEED = 75
var motion = Vector2()

func _physics_process(delta):
    if Input.is_action_pressed('ui_right'): motion.x = SPEED
    elif Input.is_action_pressed('ui_left'): motion.x = -SPEED
    else: motion.x = 0
    set_global_position(get_global_position() + motion*delta)
    print(delta, position)

---

KinematicBody2D, _process(), set_global_position()

https://youtu.be/YVFtkbuyqEQ

extends KinematicBody2D
const SPEED = 75
var motion = Vector2()

func _process(delta):
    if Input.is_action_pressed('ui_right'): motion.x = SPEED
    elif Input.is_action_pressed('ui_left'): motion.x = -SPEED
    else: motion.x = 0
    set_global_position(get_global_position() + motion*delta)
    print(delta, position)

---

RigidBody2D, _physics_process(), apply_impulse(), camera smoothing on

https://youtu.be/MGMlhl0tPTA

extends RigidBody2D
const SPEED = 7
var motion = Vector2()

func _physics_process(delta):
    if Input.is_action_pressed('ui_right'): motion.x = SPEED
    elif Input.is_action_pressed('ui_left'): motion.x = -SPEED
    else: motion.x = 0
    apply_impulse(position, motion)

I may have amplified the jittering by using apply_impulse() like that but modifying the position of the object directly using set_position() didn't make much difference.
EDIT: Changing the process mode of the camera to CAMERA2D_PROCESS_PHYSICS solved the severe jittering of rigidbody itself.

---

I'm about to sign a deal with a publisher with my game that I made with Godot and because of the jitter I might have to move all my codes to Unity. Time and cost to move all the codes put aside, I'm reluctant to switch to different engines because I really like the design philosophy of Godot and Godot itself.

I also noticed that in 3.1 'Physics Jitter Fix' option has been added in the settings menu ( https://twitter.com/reduzio/status/984783032459685890 ) but that doesn't seem to help solve the issue.

[Ploppy3]

Did you try without spamming the console? It can have a pretty significant impact.
As example: remove the print(...) line 15 of your _character.gd_

Edit: On my side, I can clearly see it stuttering with the print calls, and not without them.

[diiiiiiiii]

@Ploppy3 Yup I tried without it. I wish the solution was that simple... I really don't wanna switch to Unity.

[Xrayez]

This might work better when exported, maybe try to experiment with Vsync in project settings. If you have dual monitor setup with different refresh rate this could impact stuttering in my experience. In my case it would work smoothly on 1st monitor, while stuttering happens while debugging the game on 2nd monitor, for instance.

[diiiiiiiii]

@Xrayez I read comments on different threads about turning on or off Vsync making the issue disappear or at least less severe but in my case, it didn't make any difference.
The only thing that seemed to make it less severe was setting physics fps to higher than 60.https://github.com/godotengine/godot/issues/17823#issuecomment-431084637
But it didn't make the issue disappear and the difference was negligible.

[eon-s]

@diiiiiiiii can you try with 3.1 beta? there were many fixes in KB2D, Camera2D and Viewport, also the Camera has a new update mode (physics) in the properties which may help on some cases.

[diiiiiiiii]

EDIT: Changing the process mode of the camera to CAMERA2D_PROCESS_PHYSICS solved the severe jittering of rigidbody itself.

@eon-s Yeah I've been testing with 3.1beta2. And it did fix the jitter of moving object itself when camera smoothing is on. But unfortunately overall stutter is still there.

[eon-s]

As a workaround while this is being investigated, the camera with smooth issue could be replaced by custom code to move the viewport and make a smoothing that moves and rounds positions on physics process.

Related issues (some comments may mention other workarounds):

2667

16918

17823

23758

[eon-s]

Wait, I think I have read it wrong, smooth enabled fixes some jittering?

[sicienss]

I am working in 3.1 beta 2, and thought I'd share my experience.

I notice periodic stuttering on my background when I am running in windowed mode in my native resolution (640x360), but it is perfectly smooth in fullscreen. There is a stutter about every half second.

I also notice that the FPS while windowed oscillates between 58 and 59, but while in fullscreen it is a smooth 60.

Changing the camera's process mode has no effect.

Not sure if this is related to the reported issue.

[eon-s]

Tested the sample project, got some stuttering on the background (Ubuntu, R5, godot 3.1b2), irregular and it do not seems to be related to physics, looks more like a floating precision issue because zoom is low, motion is also slow...

[sicienss]

I also tested the sample project (Window 8, Intel HD Graphics 4600, 3.1b2).

I also noticed stuttering on the background. For me, it was more pronounced and happened about every second. Commenting out the print() line didn't help.

When I put the test project in fullscreen, I did not notice the stuttering.

Tried to screen capture, but the quality isn't very good, so I'm not sure it'll be much help.

[eon-s]

I was playing a bit with refresh rates, with vsync off forcing fps to match the monitor (60 and 40) the stuttering was gone, could it be possible that the engine is not taking the correct vsync values or not applying it?

[girng]

i changed _physics_process to _process and removed print, seems like jitter is gone for me
OS; w10, 64-bit, 144hz monitor (gtx 950)

if you are still having this issue and don't want to move to unity... i recommend using _process and custom camera movement underneath it (if the camera2d node is the culprit, however, it should work fine there's been some work on it lately)

and yeah if i run it using physics_process it's insanely jittery (non playable)

[sicienss]

@eon-s , I tried this as well, in both the sample project and my full-scale project.

I disabled vsync and hard-coded the FPS to match my refresh rate (60 Hz). It pretty much got rid of the stuttering!

I wonder why this is. As I mentioned before, when vsync was enabled, I never noticed the stuttering in full screen—only windowed. Could it be that vsync is working properly in full screen mode but not in windowed mode?

[diiiiiiiii]

RigidBody2D, _physics_process(), apply_impulse(), camera smoothing on

https://youtu.be/MGMlhl0tPTA

@eon-s Camera smoothing is enabled only in the last code example. And unlike the stutter of entire screen or objects, which occurs in all code examples, when camera smoothing is enabled the moving object(RigidBody2D, KinematicBody2D, etc.) itself jitters back and forth viciously. And changing the process mode of the camera to CAMERA2D_PROCESS_PHYSICS solved the jittering of moving object itself but not the overall stutter.
And I'm sorry if I made any confusions. English isn't my first language.

Tested the sample project, got some stuttering on the background (Ubuntu, R5, godot 3.1b2), irregular and it do not seems to be related to physics, looks more like a floating precision issue because zoom is low, motion is also slow...

Since the issue remains even without the camera, I don't think it's related with zoom.

---

KinematicBody2D, _process(), set_global_position()

https://youtu.be/YVFtkbuyqEQ

@girng In the third code example, _process() was used instead of _physics_process(). I haven't tried the custom code for camera movement though. Yet again, it happens even without the camera.

---

@sicienss I read several comments in related threads about fixing fps and I tried fixing it to 60 and 40.(Whether Vsync is enabled or not didn't matter) And it seems like when fps is fixed to 40 or lower, stuttering happens a lot less frequently. But maybe it's because fps is too low and it becomes difficult to notice the stuttering. And also in my case, couldn't find a noticeable difference between full screen mode and windowed. But I'll test that again for just in case.

EDIT:
Test: Fullscreen
Test: 40Fps, Vsync-False
Test: 60Fps, Vsync-False
Test: No Camera2D
Test: 40Fps, Vsync-False, No Camera2D

[diiiiiiiii]

(Fps has been fixed to 60 in the settings)

I'm not sure this is normal or even related to this issue but 2nd and 3rd process delta spikes happen when the object starts moving. Is it normal to see that kind of spikes in a simple project and everything has finished loading before the movement?

[behelit2]

I'm having same problem diiiiiiiii is having in his move_and_slide use case.

2D project with kinematic characters
Godot 3.0.6
Win10 64bit
Intel i5-2550K CPU
16gb ram
Geforce GTX 970

[reduz]

Just as a side comment, you can use move_and_slide in regular _process now in 3.1, this can fix many jitter problems of having to use it in _physics_process. Although this nowadays seems it's not much of a problem.

Also stutter is most of the time OS related. When you go full-screen, both OSX and Windows give your process more priority so it gets interrupted less. If you don't see stutter full-screen, it sounds like some background task is the culprit.

Also, removing the print, I don' t see any stutter at all in your demo under X11. On Windows, I see occasional stutter (background task most likely) when windowed and nothing at full-screen. This is perfectly expected.

[behelit2]

@reduz I have seen the same results you have with X11, it runs flawlessly. However, I don't think it's wise to quickly blame the problem on background processes in Windows and OS-X. After all, 2D games in other engines/frameworks (Unity, XNA, etc) run flawlessly in Windows and OS-X without any noticeable stuttering. That tells me there is something those other engines are doing right, that Godot is doing wrong. Thus, it could be OS related, but also Godot related as well. Is my logic incorrect here?

[eon-s]

@reduz can you give more details about using move methods outside physics process? That may need to be documented and mentioned in tutorials too.

Ping @kidscancode @gdquest

[reduz]

@behelit2 I don't know. If you or anyone else wants to investigate, here is something I suggest trying:

• Try making a similar project in Unity, XNA or whatever you like
• Try running this project windowed in both DirectX and OpenGL (I think you can use OpenGL on Windows in Unity)
• Investigate the priority of the running process in the task manager (go to details).

Let me know if you see anything odd.

[reduz]

On Windows, If I force the priority of this demo above normal or high, stutter goes away completely too. I Wonder if other engines to do this somehow.

[diiiiiiiii]

@reduz I was about to write a similar point that behelit2 has addressed. Even my Mac is a very low powered machine, it runs simple 2D games quite well without any stutter, _in full-screen mode or not_. And this example project is way much simpler(almost empty) than those games.

On Windows, I see occasional stutter (background task most likely) when windowed and nothing at full-screen. This is perfectly expected.

So it's a bit difficult to agree with you on expected stuttering on simple 2D project like this when it's not on full-screen mode.

Also as I mentioned above, it happens on ios(including iPad pro) as well which handles Fornite without a sweat.(But to be fair I haven't tried the example project on iPad pro. Only my full game. I'm planning on testing the example project on iPad pro tomorrow or so.)

[reduz]

@diiiiiiiii I tried your demo on Windows on high priority and stutter goes away when windowed. Apparently changing the priority manually is possible on Windows:

https://forums.ogre3d.org/viewtopic.php?t=83225#p518528

I am not so sure it's possible in OSX, though.

[eon-s]

What about forcing high performance settings on the GPU? maybe godot is detected as a regular app and the OS optimizations try to reduce the resources used by the program.

[reduz]

@eon-s I dont think this is GPU related

[reduz]

@diiiiiiiii I raised the process priority on windows, apparently it can be set to above normal (not high or critical). This got rid of the stutter for me (though it still does a bit of stutter for 3/4 seconds after loading, then goes completely smooth).

If you can build from master and test, let me know if it helps. On unixes doing something like this is impossible (though I see no problems on X11). Maybe OSX has something similar, but I don' t know much about the platform.

I personally never seen jitter/stutter on Android or iOS. Please test this with Godot 3.1, which fixes some jitter issues in all platforms.

[reduz]

For OSX there seems to be a really strange OS bug in fullscreen and the fix is pretty hacky. It affects most engines and libraries. If anyone with OSX wants to investigate and try any of the solutions mentioned here, feel free:

https://github.com/glfw/glfw/issues/772

[homarox]

I have the same problem with a simple endless running game. I had the test on Linux, Window10 and Android devices (Samsung s6, Samsung Note 5, Xiaomi 6X) and try all ideas above, but it does not work for all test devices :(

[Shin-NiL]

@homarox endless runner is the type of game where this issue is more noticeable. I remember to see it when I was prototyping a game some time ago.

[homarox]

@homarox endless runner is the type of game where this issue is more noticeable. I remember to see it when I was prototyping a game some time ago.

Does it have any best solution for this situation? FPS looks seem good, I also tried VisibilityEnabler2D to enable animation only node on viewport but not helpful.
And it's happened more frequently when your game runs long time enough.

[reduz]

@homarox what version of Godot are you using?

[homarox]

@homarox what version of Godot are you using?

@reduz I am using Godot 3.1 Beta 2

[reduz]

Added this guide in hopes of getting better reports on these issues:
https://docs.godotengine.org/en/latest/tutorials/misc/jitter_stutter.html

[starry-abyss]

For me this project on 3.1-beta2 on Win 7 runs sometimes smooth, sometimes jitters at different frequencies (but the frequency of jitter is kept for several seconds), but most of times it stutters about once in a second (either alone or together with jitter). By "sometimes" I mean that those cases are switched during the same one run of the game.

Increasing process priority doesn't seem to help.

I had an idea that this is the kind of error similar to camera jitter in pixel art games when the positions of everything is rounded to integer every frame (and the characteristics of jitter depend on things like camera settings and fractional part of player's position). But don't have a clear idea of how to prove or disprove this theory.

[starry-abyss]

Windows is known to cause stutter in windowed games.
Stutter may be visible on Desktop Linux, [...] associated with [...] compositors.

I'm almost sure that this is about #19783, and think v-sync should be turned off automatically (by the engine!) when in windowed mode. But need more feedback to confirm.

[reduz]

While turning off vsync makes it smooth, this entirely because of brute force. This will make the game use a huge amount of CPU (and battery on laptops) so it should be avoided.

I still am not sure whether:

• This is avoidable on Windows in some way, maybe it's not.
• This has to do with how OpenGL or how OpenGL does buffer swapping (this is why I think it can be interesting to test a similar demo in Unity running in both OpenGL and DirectX. Volunteers who have Unity installed welcome.)

The source of stutter definitely does not come from Godot, but I wonder if anything else can be done from our side.

[reduz]

Well, in any case, we will soon see how this works in Vulkan, which does all the swapchain work manually.. should be easy to tell if anything is wrong there.

[behelit2]

@reduz So... I'm not sure where you get the idea that Windows is a stutter prone operating system. It is the most common gaming OS for desktops and laptops. This is because most games, despite your apparent misconception, run really well for the most part. I do not understand why you won't consider Godot as a potential source for the problem.

I can play Starbound (a highly complex and sophisticated 2d game utilizing procedural terrain generation) for literally hours on end (in both windowed mode and full screen) without even the faintest hint of stuttering. I go to check the process priority, and it is set to normal. All manner of emulated 2D titles, from any 2D game system you can think of, run perfectly with no stutter (and have been doing so since 2001). Yet, simple 2D games in Godot with a single background layer exhibit frequent stuttering.

I don't mean to be offensive, but it really seems like your explanation of background processes and OS issues is avoiding a legitimate problem here. Cuphead, a game with insanely detailed 2D graphics, would not have sold millions of copies if it exhibited frequent stuttering in Windows. If you actually played many 2D games in Windows, you would realize that blaming background processes is barking up the wrong tree. I understand that solving this issue probably isn't going to be an easy fix. I understand this is something Godot has been struggling with for a long time. But this is a very real problem and sweeping it under the carpet by pointing your finger at the OS is not going to make it go away. As more users adopt Godot, more people are going to notice this, and eventually Godot will gain a reputation for being a terrible 2D game engine.

This is not an attack, but a heartfelt concern. I really like Godot. I have fallen in love with GDscript and I think the interface is extremely intuitive. I want to see it succeed. But this stuttering is like a thorn in it's paw...

[starry-abyss]

@reduz

While turning off vsync makes it smooth, this entirely because of brute force. This will make the game use a huge amount of CPU (and battery on laptops) so it should be avoided.

No, because besides turning v-sync off I also suggest to cap the framerate. This way the game would use the same amount of CPU.
I see v-sync as a measure to fix vertical frame tearing, and I don't understand why it's taken for granted here that it is also an universal way to cap the framerate.

I recently tested the project in the other issue I'm pointing to, and turning v-sync off clearly helps on my PC, while still with framerate of 60!

I'm interested in testing different stutter/jitter demos too (Godot or not) and giving feedback. Maybe we should create a tracker meta-issue where all of those projects/issues are collected? (without the hot issue discussions, only pointers to issues and summary of what helped in each case)
Also, I'm personally totally OK with it all dealed _after_ 3.1 is released.

The source of stutter definitely does not come from Godot, but I wonder if anything else can be done from our side.

I agree, but if some setup makes smoothness for 90% of cases, IMHO it's in interest of Godot project to make it the default one.

That said, the issues we have are different ones with different causes, and some of them probably are very game-specific and can only be dealed with from the game's side. So I suggest dividing them and treating one by one instead of seeing them as one united unavoidable mess.

[diiiiiiiii]

@reduz I took a bit of time and tested in several kinds of settings. And the results were

• In 3.1 beta 2, generally stutter was almost gone in Windows and iOS.
• In the example project, it was completely gone.
• There were still a noticeable amount of stutter left in my full game project.
  
  
  
  • But it got way less severe compared to 3.0.6.
  
  
• Also setting the process priority did help a lot but full-screen mode didn't.
• MacOS is a totally different story. It still stutters and jitters like crazy even in the example project.
  
  
  
  • And there's also no noticeable difference between playing it in full-screen mode or not.
  
  

Jitter fix in 3.1 did work very well. So I'm wondering, wouldn't it mean that there could be a bit more that can be fixed or optimized in Godot?

[reduz]

@behelit2 I don't know if this is a Windows problem or an OpenGL driver problem. It definitely is not a Godot problem for the simple reason that:

1. It works fine full-screen, and in most other platforms
2. Godot does absolutely nothing that could cause stutter in such simple demos. There is no code that can be checked becuase nothing platform dependent that could be causing this exists in the codebase.

Most games on Windows are DirectX games, where you have more control on how vsync is performed, so it is very possible this definitely is OpenGL related. This is why I ask anyone interested to try the same simple demo in Unity or another OpenGL based engine.

[reduz]

@starry-abyss Disabling VSync and capping FPS is a horrible idea. It's just wrong because you are relying on the system scheduler caling a delay() function, which has 3 problems:

• It is a relatively low precision function
• the time you wait by using delay() is processing time taken away from your game.
• There are monitors with different refresh rates, and that _will_ give you jitter.

VSync is designed to solve this problem and run your game as efficiently possible. It works using an interrupt directly from the GPU that unblocks your render thread at the very precise time it has to. It should _never_ be turned off. The problem here is, in my opinion, either OS related or OpenGL (driver or wgl) related.

[reduz]

Again, we will see soon how all this works in Vulkan.

[behelit2]

@reduz I disagree with your reasoning.

1. It does NOT work fine full-screen. I tried diiiiiiiii's example in 3.1 beta 2 in full screen and the stuttering is clearly still present in Windows 10. Maybe not as severe as the video, but it's totally there. Maybe try doing 2-3 passes over the bars to see it, it's kind of a short example.

2. I accept that you are a "game industry veteran with over 20 years of experience". But saying there is absolutely nothing that could cause stutter in Godot is hubris. Saying there is no code that can be checked, in any reasonable development setting, is ridiculous!

The Starbound example I quoted... Is OpenGL. It runs exactly the same in Linux as it does in Windows 10. Full screen or windowed, it runs for hours without a single stutter. I could probably quote a dozen similar examples where this is the case. Immensely complicated games that use OpenGL, that run multiplatform... Run without stuttering. We shouldn't have to "prove it" with example projects in other game engines... Because there are WHOLE GAMES where this kind of stuttering never happens.

I mean no offense. I hold you in the highest respect for your efforts with Godot. But at some point, reality has to hit! There are so many unresolved issues with 2D stuttering and the solutions I see are like a sledge hammer, when this clearly needs a scalpel.

[Shin-NiL]

Again, we will see soon how all this works in Vulkan.

Would not it be more interesting first to try to solve the current issues (like this one) before starting to work on new functionalities? What I fear is to repeat the same cycle that was the migration from OpenGL 2 to OpenGL 3 which for me, as user one old engine user, was very traumatizing.

[DDru]

In Unity3d, this problem occurs if you move the camera through Vector.Lerp. The camera does not have enough time for set position if the objects are moving. Helps use Vector.Smoothdamp.

Also many years ago I got this problems in BlitzBasic3d and BlitzMax on winXP, win7. Me helped the use of delta time together in vsync. Function move_and_collide use delta time?
This line with delta time work perfectly on my win10: motion = move_and_slide(motion * delta, Vector2(0, -1))

[reduz]

@Shin-NiL change should hopefully be very minimal this time compared to 2.0 -> 3.0 migration. Most will stay as it is and it's mostly an internal rendering change rather than a full engine rewrite.

[behelit2]

@reduz Okay... Now I feel bad. I just tested my main project in 3.1 beta 2, and I did notice a SLIGHT improvement in stuttering. It's less noticeable now, but still there.

However, I'm really excited that the intermittent jitter in Camera2D smoothing is fixed! It works perfectly now. I can report issue #17823 as resolved.

[reduz]

@behelit2 You are definitely misunderstanding me. What I mean is that whatever is causing the problem (IF there is a problem) is no longer in the platform-independent code in 3.1 (this was fixed), but must be something related to the platform-specific wgl code (the windows GL context management). Checking the wgl implementation I can't see anything strange or out of place.

Looking on the internet, I find people with similar issues using OpenGL but nothing seriously seems like a good fix either (suggestions range from disabling vsync to forcing flush before swapping buffers, all previously proposed).

Maybe the games you tried use these, but I think the stutter is not as bad as to justify anything like that (I see at much once small stutter per minute, even on a crappy computer), these fixes are overkill.

[reduz]

@behelit2 btw, I have a Windows 10 PC with the same spec as yours (i5-25xx) except nvidia 1050 instead of 970. Running @diiiiiiiii 's demo on fullscreen there is no visible stutter running for a while, and windowed I do see stutter but only the first 3/4 seconds.. then it goes away to only come back every a very long time. Is this what you see also?

[behelit2]

@reduz Sadly... No. When full screen, I do see a stutter at random intervals. Sometimes when I run it, there will be no noticeable stutter. Other times, it will stutter several times within 10 seconds. It really does SEEM like a interfering process, like you said. But I'm not sure how that's possible when the CPU time on diiiiiiiii's example hovers at 2% or less and nothing else is using CPU. Could it be because I'm running at 1440p desktop resolution? haha

Windowed, it stutters pretty bad, every few seconds or so. Certainly much worse than full screen.

Which is odd... Because when I go to test my main project, it runs really smoothly in Windowed mode. Only the occasional, random stutter just like full screen. Madness! (O___0)

Edit: You make me want to buy a 1050 for testing.

[fracteed]

As someone who has struggled with similar issues(In Win10), I have achieved the smoothest results by turning off the vsync in Godot and not forcing the framerate (keep it at 0). For Godot it is better to turn on the vsync option on your GPU, and leave it off it Godot. Strangely enough I had a lot more issues getting my 2d game to run smoothly than I did for my 3d games, though I have no idea why!

I do suspect that OpenGL drivers have a lot to do with these repeated issues, as most Windows games use DX and run fine for me on all my machines. Hopefully the move to Vulkan will eventually solve the common issues that people are having ...namely shader compile pauses, intermittent stutter/jitter and better performance on lower hardware (especially intel integrated gpus).

[girng]

@reduz

This is generally not a problem, given that refresh rates higher than 60 Hz are barely visible to the human eye, and starting with Godot 3.1, a frame timer was introduced that tries to synchronize with refresh as best as possible.

anything above 75hz monitors is noticeable. especially at 100+. this might be why godot has these stutter issues, the main developer needs a high refresh rate monitor for testing! it would help a lot. the problem is the customs at his country make it very hard to import electronics, and it's quite expensive as well (+ the heavy import tax)

edit: another issue that i see all the time (since 2014), no one posts their monitor's refresh rate in these issues, it should be listed, it's important! everyone has their stuttering issues, but the main dev's PC (or anyone replying) is at 60hz.. so they say no stutter, then the issuer says yes there is stutter! and vice versa.

[eon-s]

Are all the tests being done with the editor opened or exported release projects? the debugger (mostly the remote tree) loves to interrupt the running game.

@DDru move_and_slide uses delta step internally, but the problems with KB and updates was supposed fixed on 3.1

[Ploppy3]

Complains do nothing else than slowing the process of fixing the bug by making this thread completely unreadable, if you don't bring information to the topic, then refrain.

I think at this point we need to be much more organized.

First we all need to agree on the terms, and @reduz already wrote a great post on this.

We also need as much information as possible when doing a report so I created a basic template (Improvements are welcome):

• Godot version:
• Platform + version:
• CPU:
• GPU + driver:
• GLES2 or GLES3:
• Fullscreen / Windowed:
• Debug or Exported:
• V-Sync On / V-Sync Off + framerate limit:
• Monitor refresh rate:
• Native resolution:
• Apps currently running:

I noticed 2 things that can significantly decrease the performance (in debug), don't report anything until those are disabled:

• Spamming print calls (not tested with exported project)
• Remote Tree will also degrade performance

I did a cleanup on @diiiiiiiii 's test project, this idea is to create a project as simple as possible as a base for our future tests with almost everything set to default to have the highest chance to identify the problem. Improvements are welcome!

• Reset all project's settings to their original values
• Rename scenes and scripts
• Removed unused code
• Removed commented code
• Switched to sprites (from animated sprites)
• Removed camera zoom, smoothing and drag margins

_test_jitter_stutter.zip

---

My test and what I found:

• Godot version: 2d57ec2
• Platform + version: Windows 10 - 1809
• CPU: i5 2500K
• GPU + driver: GTX 1060 (417.22)
• GLES2 or GLES3: Mixed
• Fullscreen / Windowed: Mixed (see below)
• Debug or Exported: Debug
• V-Sync On / V-Sync Off + framerate limit: V-Sync On
• Monitor refresh rate: 60hz
• Native resolution: 1080p
• Apps currently running: godot editor (even disabled anti-virus)

I used the no_physics_character scene

What I noticed, not much jitter, if any, but a constant quite noticeable screen stutter/freeze no matter if:

• Windowed / Fullscreen
• GLES2 or GLES3
• apps running or not
• player moved or not (no input)

Example fullscreen-gles2:

Example windowed-gles3-noinput:

Edit: Notice the spike in the process time chart, which always happen after a few seconds (variable) and result in a stutter/freeze, I did not test further to see if it was recursive.

[behelit2]

@Ploppy3 Now that's what I'm talking about!

Godot version: 3.1 Beta 2
Platform + version: Windows 10 - 1803
CPU: i5-2550K
GPU + driver: GTX 970 (411.70)
GLES2 or GLES3: Both used, see below.
Fullscreen / Windowed: Both used, see below.
Debug or Exported: Debug
V-Sync On / V-Sync Off + framerate limit: Vsync Enabled.
Monitor refresh rate: 60hz
Native resolution: 1440p
Apps currently running: Godot editor, Notepad (for writing this stuff down).

*INFO: For these tests, I will be using the modified project provided by Ploppy3. I did not find the FPS/Process graphs meaningful, they were always similar or identical to Ploppy3's examples, so I will not be providing them. In all cases, the time interval between stutters seemed random, with no discernible pattern. Only a rough rate could be observed.

RESULTS FOR: no_physics_character

GLES3 / Windowed : Significant stuttering every 1~2 seconds.
GLES3 / Fullscreen: At least one major stutter every 10~20 seconds.
GLES2 / Windowed: Significant stuttering every 1~2 seconds.
GLES2 / Fullscreen: At least one major stutter every 15~20 seconds.

RESULTS FOR: kinetic_character

GLES3 / Windowed : Significant stuttering every 1~2 seconds.
GLES3 / Fullscreen: At least one major stutter every 10~20 seconds.
GLES2 / Windowed: Significant stuttering every 1~2 seconds.
GLES2 / Fullscreen: At least one major stutter every 10~20 seconds.

RESULTS FOR: rigid_body_character

*NOTE: Motion completely different than the other two.

GLES3 / Windowed : Heavy stuttering every 1~2 seconds, then seemed to settle down to one major stutter every 10~20 seconds after a while.
GLES3 / Fullscreen: At least one major stutter every 10~20 seconds.
GLES2 / Windowed: Heavy stuttering every 1-2 seconds, never settled down.
GLES2 / Fullscreen: At least one major stutter every 10~20 seconds.

@reduz @Ploppy3 Do you guys have any ideas for how we can make more accurate rate/frequency measurements on the stuttering? I didn't find anything in the monitors section that could reliably do this.

[eon-s]

Try to do some tests on release too, it may increase or reduce the importance and change the focus of the issue (to see if the debugger is the source and/or the OS locks the debugger making things worse).

[behelit2]

@eon-s I will do a full set of tests on exported releases... But I kinda want a more accurate way of detecting stuttering. Eyeballing it feels like a very unscientific method for doing this. Furthermore, if printing to the console generates stuttering, I'm not sure how to go about doing it. I will need to do more research on this. Worst case, I can eyeball it and use a time-stamping app on my phone. If anyone has a method for accurately recording the stuttering in discrete time measurements (that doesn't produce stuttering itself), please share!

[reduz]

@behelit2 can you do the following?

• Go to the project folder using command line
• run it by writing c:\path\to\godot.exe

see if it has more or less stutter than when running from editor.

[diiiiiiiii]

The Elusive Frame Timing - Alen Ladavac - Medium
Found in @reduz's tweet thread.
Thought it might be helpful.

[eon-s]

@diiiiiiiii thanks! I have seen it once and could not find it anymore.

If I got it right, a way to patch this _while we wait a couple of decades for decent graphics API_ may be to get an average of frame time from a small sample and use that instead of the real frame rate?

[Ranoller]

I don´t want to repeat the test we did in this thread: https://github.com/godotengine/godot/issues/19783 but there are some things that are needed to do until confirm that a game stutters:

1. Like other user says previously... disable all prints to console because print is very slow and stutters.
2. Minimize godot editor: Godot editor render makes the executed game stutter.
3. Execute a semi-complex project to test. A very simple project (at least in windows) allways stutters. I think this is because windows multi-tasking or windows compositor priorities.
4. Check that remote scene tree is disabled. Remote scene tree stops periodically the main thread.

Once this is done, there are some stutters that i find in my 3 configurations (3 different computers):

1. Initial Stuttering. Godot stutters some seconds at the running start. Later it stabilizes.
2. Focus gain- focus lost. the same stutter that "initial stuttering" but in focus gain. I think that this is the worst stutters, because it gives bad impression of the game.
3. Stutter in multi-screen systems when the windows compositor have the main screen fliped with other screen and the game is not executed in the new main screen. I think that this is an OpenGL thing because it happends too with Chrome (but not with unity games)
4. Stutter when other OpenGL aplication is rendering: Ex: Godot stutters when Chrome is playing a youtube video, but youtube video stutters to....

This stutters do not come from godot (the reproduction maintains 60 fps stable and don´t have spikes) but are related with the the way that godot do the things (doesn´t happend in Unity-SDL-XNA or Game Maker projects in my configurations).

The resume of the investigation with other games of this thread (https://github.com/godotengine/godot/issues/19783):

· Vast mayority of steam games are 32 bit. (Recents too)
· Godot executes 2 types of rendering calls (OpenGL and Windows GDI). All games tested execute only one type (see the thread and the app used to see the processes) no matters OpenGL or DirectX rendering. This can be because the steam overlay, i don´t know, but not all games uses that.
· A lot of steam games don´t allow to resize screen, or moving screen. Can it be related with the above?
· A lot of steam games pauses reproduction in focus lost.
· Vast mayority of steam games are DirectX.
· Most steam games almost not stutters, maybe one or two stutters at hour of reproduction but not every X seconds and some games never stutters (Ej N++, visually simple game that never stutters, no mather time of playing), so is possible to do an "stutter free" environment.

My opinion is that _we need to stop the stutter test with the "Simple project"_ (testing if a sprite moving in screen stutters) because this stutter is gone when the project becomes more expensive for the CPU and the GPU, and we need to focus in the stutters that happends at the beggining of the execution, every x seconds in the execution, the focus gain- focus lost stutters, and the stutters asociated with the camera, physics, etc.... because at the end this kind of stutters will be the problem that final user will experiment...

All of this are from experience and not qualified opinion: not an engineer here.

[diiiiiiiii]

@Ranoller I think some parts that you are addressing are overlapping with what @Ploppy3 have already said.

because this stutter is gone when the project becomes more expensive for the CPU and the GPU, and we need to focus in the stutters that happends at the beggining of the execution, every x seconds in the execution, the focus gain- focus lost stutters, and the stutters asociated with the camera, physics, etc

I agree on the importance of fixing the initial stutter but I find it hard to agree on "stutter naturally disappears on complex projects" since as the project becomes more complex, the issue only gets worse in my case. And like I already mentioned before, the issue happens even without any camera node or physics functions.

(the reproduction maintains 60 fps stable and don´t have spikes)

And also we did get reports on spikes in process delta and fps from several people including myself.

[reduz]

@diiiiiiiii I know that article, and also was familiar with that problem, but there is nothing that can be done in OpenGL (and platforms like iOS and Android). This is why I asked you guys to test the same thing in Unity (in GL vs DX) and why I mentioned that port to Vulkan may definitely help, as you have more control over the swapchain.

Still, process priority does have an influence on stutter, which is why on Windows-fullscreen you see it less.

[diiiiiiiii]

@reduz Yeah. Process priority did work for me, unlike full-screen mode.
I will try to test it in other engines. But due to my inexperience in Unity(since it could lead to inaccurate test results), I'd prefer someone else would do the test or make the test project in Unity.

[behelit2]

@reduz Sorry, I haven't had time to test and won't be able to get my hands on a Windows box until tomorrow. But I read that article that diiiiiiiii shared and now I'm intrigued. Could there be a miscommunication between the CPU and the GPU, causing the behavior shown in the article? This seems not only possible, but highly likely. In fact, it's the most likely explanation I've seen. Could it be... That (OpenGL/Multi-platform) games with no stutter are "cheating" a bit? I quote from the article:

"What happens here is that the game measures what it thinks is start of each frame, and those frame times sometimes oscillate due to various factors, especially on a busy multitasking system like a PC. So at some points, the game thinks it didn’t make 60 fps, so it generates animation frames slated for a slower frame rate at some of the points in time. But due to the asynchronous nature of GPU operation, the GPU actually does make it in time for 60 fps on every single frame in this sequence."

Is there any way we could test that? Disconnect the "timing shenanigans" and just pretend it's always going to run at 60fps no matter what? Because, lets be real here. With the speed of computers, multiple cores, test projects that only use 2% CPU time, and the other 97.9% of the CPU is free? THERE IS NO WAY it's interfering processes. I have never seen any games with a default process priority above normal.

[reduz]

@behelit2 The problem is that the time elapsed between frames in the logic side is not necesarily the time between frames being presented (screen hz). The right solution would definitely be to get this timing from the GPU driver, or have more control over swapchain to get more precise timing (afaik what you do in DX12 and Vulkan). Then again, not possible in OpenGL.

[starry-abyss]

@Ranoller

My opinion is that we need to stop the stutter test with the "Simple project" (testing if a sprite moving in screen stutters) because this stutter is gone when the project becomes more expensive for the CPU and the GPU, and we need to focus in the stutters that happends at the beggining of the execution, every x seconds in the execution, the focus gain- focus lost stutters, and the stutters asociated with the camera, physics, etc.... because at the end this kind of stutters will be the problem that final user will experiment...

I think that this statement is contradictory. To repro most those stutter/jitter types one by one, I think it's worth it to find a minimal project which clearly decouples one case from another ones (e.g. for that other thread's project I have a stable workaround, while for this one it _doesn't_ work) - or a clear idea what OS/hardware set up is required to repro.
Some cases are impossible to solve (or impossible to solve universally), like in the Talos Principle article (BTW, Talos Principle has that camera move freeze issue for me in Vulkan beta mode - not article one, but shader one), but not all of them.
That said, let's allow dear developers to make a 3.1.0 release first...

[Ploppy3]

@reduz Even though I don't run into the jitter issue at all while in full-screen, I run into the stutter one which I explained quite in detail here ; you may have missed it. I would like to get your opinion though. I can give you more information and can do more tests if you want.

[Ranoller]

Win 7 without aero doesnt stutter in full screen. With aero can stutter. (it's seem that aero doesn't allow real full screen)

Win 8+ to win 10 can stutter full screen or not.

This stutter should be gone by doing an intensive project except multitasking interferences , more that one opengl aplication execution, godot editor rendering with the game, other godot instance execution, etc.... some times other godot instance can increment the processor/gpu requirements and magically the stutter is gone. There are now a bunch of issues that test this things. (Are referenced here and there)

[Ploppy3]

This is what the profiler gives me when it spikes:

https://i.imgur.com/yCIkwfq.png

Spike:

Followed by extremely low values (probably to counter the spike):

Other than that the graphs are constant at 16ms

NB: I just did a fresh start on Windows so my PC can't be any cleaner.

[eon-s]

@Ploppy3 that spike is usually the debugger itself, when updating the remote inspector and other stuff, you may be able to get some data in a exported debug game with Performance class to exclude editor interference and drop in a log file to check if the spike is there too (still may produce its own stutter if not in release mode).

[Ploppy3]

@eon-s As I explained in my original comment the stutter is there too when exported, so it's in no way related to the editor itself.

[Ranoller]

An stutter caused by a excesive large frame should be fixable inside godot or inside your own code...

[starry-abyss]

@Ranoller What you describe sounds like a compositor problem. Windows compositor uses v-sync too, and requires some workaround (like https://github.com/godotengine/godot/issues/19783#issuecomment-456965634) to delay the game's frames. Otherwise, in my understanding, the compositor will sometimes take previous frames of the game, and sometimes - new ones.
Aero is the compositor, and in Win 8 and above it can't be turned off. But it's not an option to turn it off anyway, because for me on nvidia it stops using v-sync then, and all windows are vertically teared (not only one game).
The "intensive project" you're talking about, I guess, just naturally happens to delay frames after v-sync.
Pity, that for MacOS it's OK to include some hack for v-sync straight away, and on Windows we argue about "going only the right way", but some time we'll get there hopefully. :)

[plucian]

I tested the project on an intel 4570 (3193 Mhz) and integrated IntelHD 4600 card, Windows 10, RC3.
Stutters. Less on Full screen. I'm working on a similar game, the problem is even worse and it happens on Android too.. Maybe because large frames (2x screen) ? I'm hoping the problem will decrease as the game gets more complex..

[RaXaR]

I found the video options in the emulator RetroArch very intersting, here's a screenshot:

They have that wavy graphic in the menu background and I haven't seen it jitter or stutter once, in either fullscreen or windowed mode. I think those guys got it right. Notice all the Refresh Rate, Frame Rate and VSync options. Might be worth a look/chat with them?

[bruvzg]

My Monitor refresh rate is at times somewhere at 59.3Hz-59.9Hz

AFAIK VESA video timings (CVT) standard defines "nominal vertical refresh rates" (30Hz, 60Hz etc.) and "video optimized vertical refresh rates" with additional 1000/1001 multiplier, which gives 59.94Hz (to match NTSC 59.939Hz rate).

[Disputer]

Can't get rid of stutter/Jitter in the simplest platformer (((

• Actual Godot version
• Use Camera2d
• Base parallax background
• FTP always 60
• GLES3
• Testing on iphone 6/XR and problem is the same.

https://youtu.be/44-eq7n6hkE

Please Please help!

[Disputer]

I think this could be a reason:
https://dmtopolog.com/cadisplaylink-and-its-applications/

[golddotasksquestions]

I'm sorry I can't really contribute to the solution, but I feel the need to point out that this stutter has been incredibly annoying for me ever since I started using Godot. I am not publishing anything yet, so I was hoping for a solution by the time I would. I started using 3.0.6, but the problem exists in 3.1 and 3.2 beta1 for me just the same.
I do think it is a rather big problem, because even using nothing but the a blank project and the proposed movement code in the KinematicPlayer2D documentation tutorial, the stutter is impossible to miss. It becomes even more obvious if you increase the speed variable a bit (250 -> 600):

extends KinematicBody2D

var speed = 600
var velocity = Vector2()

func get_input():
    # Detect up/down/left/right keystate and only move when pressed.
    velocity = Vector2()
    if Input.is_action_pressed('ui_right'):
        velocity.x += 1
    if Input.is_action_pressed('ui_left'):
        velocity.x -= 1
    if Input.is_action_pressed('ui_down'):
        velocity.y += 1
    if Input.is_action_pressed('ui_up'):
        velocity.y -= 1
    velocity = velocity.normalized() * speed

func _physics_process(delta):
    get_input()
    move_and_collide(velocity * delta)

The article about fixing the stutter is simply false. Even in this minimal setting the stutter is appearing every few seconds on Windows, be it when played from the editor (windowed AND fullscreen), when exported (again windowed AND full screen).

In my projects I use velocity = move_and_slide(velocity) and various different Input code, but the stutter is just the same as in a blank project with the tutorial code above.
I really wished I would not have to wait to publish until 4.0. Who knows what new bugs 4.0 will introduce to my project? How much work it will be to transfer my project to 4.0?
I wish this stutter would have much higher priority.

3.2 beta1 minimal (incl win export): godot32beta1_stutter.zip

[Calinou]

@golddotasksquestions See discussion in #19783. As you can see, this isn't an easy problem to fix. There's a pull request open at https://github.com/godotengine/godot/pull/33414, but it needs further testing. I'll try to upload compiled Windows binaries for testing (with and without the PR commit included).

[Calinou]

I'll close this as #33414 has now been merged. We may enable that setting by default once it gets more testing.

[starry-abyss]

@diiiiiiiii Can you please confirm the new feature from the PR above helps with your issue, or is this an unrelated case?

[diiiiiiiii]

@starry-abyss Sorry, I haven't had the time to read the thread nor to test new versions for a while, but I will try to do those when I get the time.

[starry-abyss]

No worries, I just wouldn't want this issue closed unless it's really solved - in the name of jitter progress!