Stuttering issue on Unity 4.2

I can confirm this bug as well. My side-scrolling infinite runner is on hold because of this.

Please help by upvoting this issue. Here's a link to the bug in the issue tracker: MAJOR PAIN IN THE *** PROBLEM.

 

Excellent ! I am in contact with the Unity team and they are extremely responsive - which is GREAT news. Problem is, that their iOS team is not unable to reproduce the bug, so the priority is not so high - if we are talking just about Androids here. Can ANYONE here confirm this issue happening on iOS ?

 

Unity is more prone to stutter after Unity 4.x in both iOS and Android. For example, I could open Everyplay recording on iPad3 in Unity 3.5.7. Now, in Unity 4.x, I can't do that because of massive stuttering. As I said before, Unity became more vulnerable to even a tiny background process after 4.x. Can someone in Unity team comment on the profiler screens in the first page?

 

I been having the same problem for few weeks, and haven`t found any fix. tried everything Update, FixedUpdate and etc... noting seem to work. Simple few objects moving from left side of the screen towards the right has jittery/hiccups, any continuous movement is becoming a headache. Please Unity let us know what is causing this problem. My game is on hold just because if this jittery/hiccups issue.

I am having this problem on Galaxy S4, S3

Please everyone vote the issue tracker: Link

 

im sooo glad i foung this thread..man i have been have this issue for a while and nothing seems to fix it..have tried everything and still no luck. created a empty scence and few cubes with continious movement and still get the hiccups or stutter. tested this on Galaxy S4, S3 and galaxy SII X...Unity please helppppppppppppppppppppppp

hey gotys did you hear back from unity regarding this....any news

 

Short update:
a) I was able to reproduce issue on Android device
b) but I was NOT able to reproduce it on any iOS device.

So if anybody has iOS repro project please let me know.
P.S. I forwarded all my findings and link to this thread to our Android team.

 

Hi, did you tested on a iPhone 4 with iOS 7???
Any 2D scene with a sprite with a constant rotating (with a 2d rigidbody too) in update() or fixedUpdate() is stuttering. Seems like iPhone are cleaning background garbage or cache and then affects the game. The same game, on iPhone4S or iPar Air runs OK.

 

I was testing with slightly different setup. If you have repro project ready please submit it as bugreport. Thanks!

 

Are there any updates on this? I'm having similar problems with stuttering on iOS7/5s-- it's very noticeable with a coroutine that increments a counter GUI text object.

 

So far I have received no reports for iOS. Please file one if you have repro case.
Thanks!

 

Hi! I'm have the same issue. Here is my story. There are even some released games to compare the effect and simplest as possible project to reproduce the problem.

If you can't reproduce the problem, change the person to the one with better perception or just look at the profiler ;-) !!!!

 

Hi there,
I was suffering from this issue also. Trying to make 2D side-scrolling game. I have a game object that has a constant velocity on x-axis, and some sort of background sprites. When running on an android device, the background seems to be smooth while crossing the screen, but on iOS it looks a bit choppy. Making Application.targetFrameRate as 60 solved my problem on iOS.
Wish all of you the same luck...

 

Interested to know if Unity 4.5 fixes this, guys if you can maybe do a update and retest?

 

No I haven't heard back from them since they realized that this problem doesn't exist on iOS . They said if it's only Android - it's not so important to fix But reading your comments - appereantly the problem exists on iPhones too. ... I think more of you need to submit real bug report . Posting on forums will not get this issue solved - you need to bombard the Unity team with bug reports like I did - they do respond very quickly to those. So any iOS people here with the same problem - please help everyone here by submitting a real bug report.

 

It's not fixed.

 

Download 4.5 just to test if still stuttering, but its STILL STUTTERING!!!!!

 

Also glad that i found this thread. I have a new quad-core Android phone, and it laggs, stutters, hicks-up by 60fps. Thats sad. The game is really simple, like a FlappyBird with 2D Sprites. I make a comparison with Construct2 and have my game also build in there. Just want to evaluate which Engine is better suited. In C2 it runs totally smooth ! For now i prefer C2 for 2D Games. But evaluation with this buggy version of Unity3D is not really meaningful.

Would like to know, if Unity3D Devs could tell a time frame when this would be fixed. I think for all users who have a paid version of Unity3D and earn money with their mobile-games work, they rely on a stable version of Unity3D. So if any U3D-Dev reads this, it would be nice to tell the users "when" this would be fixed (this year? next year ?) ...

 

how bout cocos2d? its more famous than c2

 

Hm, heard about it. There are different versions out there? I didn´t test it yet. But as i saw it somewhere it looked like you have to have a separate editor for sprites and than go back to code editor. Seems like its splited in different apps. Also looks like only-code based. ( Nothing like snippets in unity or playmaker). Am i right here, or would you say there are many tools / plugins out there for cocos2d ? Btw. thank you for the tip !

 

Did any of you actually submitted a bug report with repro case for iOS? If so, can you please post case number here? We'd be glad to fix it, but if we can't reproduce it - we can't fix it.

 

Does it mean, that your team found this bug on Android and you already fixed it there? So you only search for a repro on iOS, cause without you can´t fix it. If so, would this fix for Android be in the next version ready? And when will be "this" next version out there ? Thanks.

 

@eanjo7 I tested a bit cocosStudio, seems powerful, but not so intuitive also the separate modules are a bit clunky. Not my flavor. Will stick further on C2. Its super fast, for game making, imho.

 

Sorry, but I have no idea, since our team works only on iOS (notice that this is "iOS Development" forum ). I suggest to ask in Android section, hopefully they can help you out.

 

Okey, dind´t noticed it. Because so much "Android" speakers here. As in post #51 there is a Link to the issue tracker.So i guess it is already noticed by the "Android Team". I will try to find a similar topic in the "Android Development"-forum. Thanks.

 

Hi, it happens to android, its just simple to reproduce, just buiild the game that has sprite animation, and then install it to your galaxy s2, galaxy s3, galaxy s4.. and you will see.

 

Im not that familiar to cocos2d too, but many sed its a very good open source engine for mobile.
Im just worried about the plugins and other stuff that unity has, and cocos dont have.

 

It doesn't matter how easy it is to reproduce it, if you want it to be resolved, you have to submit a bug report!

 

Hello guys, I have the same problem (Iphone 5, IOS 7.0), but after some steps I have fixed it. I don't know what step fixed the problem, so I will list all steps here.

I created a game using Physics2D, with character-chasing-camera. The game is very simple, just a few object with box collider 2d and a character. It is fine on Unity Editor, but when I ran it on my Iphone, the character motion and camera motion is not smooth at all, there are a lot of stutters.
So I tried adjust something:
- Open QuanlitySettings in Project Settings, set level to "Fastest".
- Set target frame to 60 in code.
- Open PlayerSettings, in "Other Settings":
+ Make "TargetResolution" to be "Auto (Best Performance)".
+ Make "Graphics Level" to be "Force OpenGL ES 3.0".
+ Edit "Target iOS Version" from 7.0 (My Iphone's iOS version) to 6.0.
Then tried to build again, and it worked! The game now is smooth like in Editor.

Hope this will help you.

 

This is happening to me as well, but on PC/Mac/Editor. I have a sidescroll runner game, and there is some stuttering going on and we are not sure what is causing it, and have found that it might be related to this thread.

 

@ZeroCartin - Do you have any info on what's being used in your scene? Types of colliders, rigidbodies, realtime shadows, etc?

 

I solved my stutter issue by setting Application.targetFrateRate = -1, and made sure to turn vSync off (set Quality settings to "Fastest". For iOS i set the framerate to 60. This completely eliminated my stuttering issue.

If this doesn't help you, then I see that the ticket mentioned above is solved in Unity 4.6.1.

 

Our game also suffers stuttering on iOS in every Unity 4 version, including 4.6.1p2. It was perfect on 3.5.7.

Our problem is with touch input stuttering but I've read this whole thread and I think the underlying cause could be the same. I've written a blog post describing the issue, diagnosing the problem and offering a crude solution.

We reported the bug to Unity (658837) two months ago but unfortunately they dismissed our initial findings as expected behaviour. That prompted us to conduct this investigation and, we think, the results are really quite conclusive: Unity 4.0 regressed a feature from 3.5.7 - the ability to regain synchronicity with the display refresh.

I have a 100% reproducible test project that demonstrates Unity blocking the main thread's runloop - this prevents the CADisplayLink's handler from firing in-sync with the hardware refresh. In short, Unity sits waiting on a semwait_signal - probably waiting for a VSYNC.

The blog post is long (really long) and it focuses on how the bug affects our game's input but it also proposes a crude solution to our problem that may fix your problem too if the underlying cause is indeed the same.

The full blog post is here. It's a series of tests that aim to prove the existence of this bug. As I mentioned, it's really long, with each test building on those before. You can jump straight to the "signal waiting" test here but unless you're familiar with CFRunLoop and CADisplayLink etc. you may find it a bit opaque. The crude solution is explained here.

I hope it helps you guys!

I'd be really interested to hear @Smilediver 's and Mantas Puida's thoughts on the conclusions we reached.

 

@cgJames, thanks for all this detailed analysis!
Actually we had one report on CADisplayLink frame stability, but it was happening on very complicated project and it was quite not easy to reproduce. So it was never linked to issue discussed on this forum. You probably could work around this problem by poking CADisplayLink to reset, when it starts misbehaving. This can be done by setting Application.targetFrameRate to 30 fps for one frame and then resetting it back to 60 fps.
I guess you are using different flavor (mean non-CADisplayLink) of main loop on Unity 3.5, which would explain why issue is not reproducible there.

I'm very happy to pass your findings and techniques how to reproduce issue to our GLES developers.
Thanks a lot!

P.S. currently we are super busy with iOS 64 bit support, so using workaround I described above, or the technique of skipping frame you described in your blogpost is the best strategy to address this issue at the moment.

 

@Mantas Puida thanks for the reply.

This problem is super easy to reproduce. It can be done 100% of the time on every iOS device we've tried: iPhone 4s, 5, 5s, 6, 6 Plus, iPad 3, iPad air. It also happens with every version of Unity 4 we've tried: 4.0, 4.1, 4.2, 4.3, 4.5.4, 4.5.5, 4.6.1p123. But it doesn't happen with 3.5.6/7 (I've not tried any older).

On 3.5.7 we're using the CADisplayLink - not one of the timers. As we prove in this experiment, the problem does exist in Unity 3.5.7 but it is capable of correcting itself really quickly - as the graph shows. This is why our game can currently only be released with Unity 3. It seems something was regressed between Unity 3.5.7 and 4.0.0.

We're in the process of trying to diagnose whether this problem also exists for Unity Android too - our initial findings suggest it does but I have nothing conclusive yet.

If the bug we've identified is the cause of the problems on this thread then it has affected a lot of people for over two years now, so I'm sure any effort to fix it would be really appreciated. 64-bit support is obviously needed ASAP, but in our case we can't release with anything other than Unity 3 due to this bug.

Please do pass on my analysis to the GLES devs and contact me if you want any clarification on the experiments I did.

 

Thanks for update! I somehow missed that in blogpost..

 

This may be completely not the issue. But I had an app with stuttering before and I found it was because I had switched the C Language Dialect in the Xcode Build Settings to GNU99, when really it should be C99.

 

Hi @techmage. The Xcode project we're using in our tests is the standard Unity-generated one. I've just checked and it's set to C Language Dialect: C99. It was worth a shot.

 

Still not fixed in 4.6.1p4. This is rendering Unity virtually useless to develop any game that requires smooth scrolling on Android (at least).
Issue 599920 is marked as fixed, but it isn't.

 

Hi Marton,

Thanks for looking at the bug. As you requested, I've tried your proposed change. I took the near-empty test project that I submitted as bug 658837 and upgraded it to the most recent version of Unity: 4.6.2p2.

I can confirm that the 658837 bug still exists in 4.6.2p2 and, unfortunately, I don't think the solution above solves the problem. My explanation is quite long - the summary is:

Calling CFRunLoopRunInMode in combination with the guard clause can help prevent Unity from repainting out of sync with the hardware and will process one extra event (if present) but it's inconsistent and can introduce an unnecessary wait into the repaint cycle. In short, my tests show the bug still exists with the proposed fix applied.

Ultimately, we all want the bug fixed and Unity updated with the best solution so please get back to me if you want any of my comments clarified.

James


And now for the more detailed version:

In this test I showed that an empty Unity project can block the main thread for the duration of the frame. This allows little time for the processing of other events, touch input etc. and can lead to a stuttering behaviour. Having studied the proposed solution, it's not clear whether the intent is to help ensure touch inputs etc. are processed or to try to stop Unity from hogging the main thread for the duration of the frame. Both are bugs but the latter causes the former so surely the goal is to stop Unity from blocking.

The proposed solution can be split into two parts:

1. _isRepainting -> a semaphore intended to prevent re-entry into the repaint method
2. CFRunLoopRunInMode -> a nudge to encourage iOS to process pending events

Looking at _isRepainting separately from CFRunLoopRunInMode:

When Unity is painting then _isRepainting will be true, otherwise false. The guard clause prevents repainting if Unity is already painting. But for the guard clause to have any effect it must be possible for repaintDisplayLink to be called concurrently. In this scenario it can't be.

This adaptation of your snippet demonstrates the problem. Note that CFRunLoopRunInMode is removed (this is v. important).

Code (ObjC):

1. - (void)repaintDisplayLink {
2.     if (_isRepainting) {
3.         NSLog(@"> skipping frame")
4.         return;
5.     }
6.  
7.     _isRepainting = YES;
8.  
9.     if(!_didResignActive)
10.         [self repaint];
11.  
12.     _isRepainting = NO;
13. }

When run, this code never logs "> skipping frame", ie. we never try to re-enter the method.

As we know, the bug doesn't always occur. It's important to test this solution when the bug is present so I added logging to show when the bug is occurring. The logging is described here and here.

In my tests, even when the bug was occurring the guard clause was not entered.

So far we've ignored CFRunLoopRunInMode to show that the guard clause alone has no effect so let's consider the two combined.

I'm having to guess at the intent of calling CFRunLoopRunInMode: given that it's called with a different mode from CADisplayLink's registration with the CFRunLoop, I infer it's to tell iOS to process any events that are pending, eg. touch events, before Unity repaints. This would address some of the stuttering input issues caused by Unity hogging the main thread.

This inference could be wrong and you may be using it for other reasons (eg. swallowing CADisplayLink signals) so forgive me if I'm wrong. Anyway, consider the logic:

• CADisplayLink has fired
• repaintDisplayLink handles the signal on the main thread
• so the main thread was free (not being blocked)
• so Unity must have finished rendering (since we're single threaded)
• so the guard clause lets us into the method
• the _isRepainting semaphore is set true
• we call CFRunLoopRunInMode(kCFRunLoopDefaultMode, 0.002f, TRUE)

and this is where things get ugly:

• perhaps there are events pending processing in the CFRunLoop (eg. touch events). The CFRunLoop is called and ONE of those events is processed (it could be two due to the nature of CFRunLoop). Unity is made aware of a touch event it could have missed. Great!

• if no events were pending then the 0.002f argument means that the CFRunLoop will sit for 2ms waiting for an event (source) to be signalled *

Since we all fight to get our frame updates under 16.67ms to achieve the magic 60fps, taking 2ms to arbitrarily wait for input is probably the wrong approach.

* we can see this by putting a stopwatch around the call to CFRunLoopRunInMode then logging the time taken to execute and its return code. If it returns 3 (kCFRunLoopRunTimedOut) then it had no events to process, but it will have occupied ~2.5ms of our repaint time.

Now things get even uglier. As I showed in this experiment, if the CADisplayLink handler (repaintDisplayLink) can't execute when signalled it will not wait for the next 60Hz boundary to run; instead, it will run as soon as possible.

If we've entered repaintDisplayLink late (off the 60Hz boundary), which is quite probable given it's one of the key features of this bug, then it's also possible that the event processed when we call CFRunLoopRunInMode is to service another firing of the CADisplayLink, i.e. we will re-enter repaintDisplayLink.

Note: although the call to CFRunLoopRunInMode uses a different mode from CADisplayLink's registration (kCFRunLoopDefaultMode vs NSRunLoopCommonModes, respectively) the CADisplayLink will still be handled if it has signalled. I find the Apple documentation a little confusing so the safest thing to do is log from repaintDisplayLink:

Code (ObjC):

1. NSLog([NSRunLoop currentRunLoop].currentMode);

Whether repaintDisplayLink is entered from the standard CFRunLoop execution or from our call to CFRunLoopRunInMode, the mode logged is always kCFRunLoopDefaultMode, i.e. the call to CFRunLoopRunInMode could handle any pending CADisplayLink signals.

Getting back on track, earlier I said it was not possible to re-enter repaintDisplayLink as we are single threaded. This is true, but when we call CFRunLoopRunInMode with a CADisplayLink event pending, we are effectively recursing into the same method - as if we'd called it ourselves. Because we've already set _isRepainting to true the guard clause prevents us repainting a second time. If we have logging inside the guard clause we'll now see it skip the frame. Given that we were about to repaint anyway (and will when CFRunLoopRunInMode returns) we've effectively dequeued a future call to repaint Unity that would likely have been out of sync with the hardware. Great! But the probability of the two events colliding is low.

If we say the hardware refreshes every 16ms (for simplicity) and we allow CFRunLoopRunInMode 2ms to process pending events then in order for us to dequeue a repaint request (as above) we would have to enter the repaintDisplayLink method between 14ms and 16ms into the cycle, ie. we have a 1:8 chance of dequeuing a pending repaint. The other 7:8 the event will still be processed later, when Unity stops blocking the main thread and the CFRunLoop can process signals again (probably out of sync with the hardware).

Furthermore, what if there were other events pending processing in the CFRunLoop when we called CFRunLoopRunInMode? The true argument to CFRunLoopRunInMode is for returnAfterSourceHandled, ie. only process one event. It's possible/probable that an event other than the CADisplayLink was processed; Unity will still paint out of sync with the hardware. And worse, the fix's behaviour is unpredictable.

In Unity 3.5.7 (where the problem existed but fixed itself very quickly) the following code was used:

Code (ObjC):

1. [_displayLink setPaused: YES];
2. while (CFRunLoopRunInMode(kCFRunLoopDefaultMode, 0.001, TRUE) == kCFRunLoopRunHandledSource)
3.     ;
4. [_displayLink setPaused: NO];

I think the 3.5.7 approach was superior because:

• if no events were present to process then it only blocked for 1ms (still harsh but better than 2ms)
• if > 1 events were present it would loop until they were all processed *
• the CADisplayLink was paused prior to running to help avoid re-entry (but not prevent it)

* it could be argued that this may delay Unity's repaint and force a disconnect with the hardware display refresh; however, those events could be touch events that need processing and, importantly, the behaviour is more consistent, ie. it will process all events, not just one.

The proposed solution may handle some touch inputs that would otherwise be missed, and it may sometimes help skip calls to repaintDisplayLink, but it does neither of these things consistently nor efficiently: it will process one extra message or block for 2ms.

If the goal of this fix is to improve touch input by handling an extra event, I think the code from Unity 3.5.7 would be a better solution. If the goal is to prevent Unity from hogging the main thread and preventing other events from being processed - surely the main goal - then the fix does not work. We can see this by adding the logging I mentioned at the beginning of the post.

With the proposed solution and logging in place I still see an empty Unity project take ~12ms to repaint*. This is quite ridiculous and shows that the underlying problem has not been addressed: Unity blocks the main thread waiting on a signal to fire.

* On an iOS device the bug can be triggered as described here.

 

Quick question, did you try it on your full scale game and does it improve touch handling?

 

I have not tried it on my production game.

I have distilled the problem into a test project so that I don't need to go to such lengths. I've applied the same tests to the solution above and I'm sorry to say it's failed.

As I've explained to you before in this thread, we have a crude work around that makes our game functional again but it might not work for everyone and I'd hope that Unity devs, with their knowledge of what occurs inside the engine, would be able to reach a better solution than us.

The solution described above can introduce an arbitrary 2ms wait into the repaint and I don't want to waste cycles on that. But most importantly, it does nothing to address the underlying blocking issue. I'm sorry to say it's a sticking plaster over quite a nasty wound.

 

Hi Marton,

Sorry for the slow reply. I've been working around a different Unity bug (655263) so haven't had much spare time.

I tried the above solution quickly in my test harness and I'm sorry to say that it exhibited the same symptoms as before: it was easy to trigger the UnityPlayerLoop to occupy the majority of the 16.6ms rendering time (~14ms). As before, this leaves little time for the processing of other events. It could be that the queue allows events through whilst Unity is misbehaving, but my initial findings suggest that it won't.

Unfortunately I don't have enough time to give this problem the attention it needs (preparing a release). Could someone else on this thread please test?

 

Hi James,
thanks for spending your time on this! Just to clarify things.. As the first step we are aiming to get a fix that probably doesn't solve blocking on vsync issue, but rather guarantees for OS to spend some time on processing events. In our local tests this showed great improvement on touch responsiveness even when most of the main thread time is spent in rendering.

P.S. we are working on vsync blocking issue too. We have some good results on Metal, but GL ES fix is still under investigation.

 

It's great to hear that the VSYNC bug is being addressed. Does the issue with GLES extend to Android? People are experiencing similar symptoms on that platform too.

 

Hi Mantas,
I am seeing this stutter in all platforms: Editor, Windows, Android. I could test IOS, but I am pretty sure it will be the same.
I verified with a simple scene with few cubes and a camera moving horizontally, tried moving it on FixedUpdate, Update,LateUpdate, all the same.

Disabling VSync make it slightly better, but it is still jittery, so it's not a VSync issue but something generic related to all platforms.

 

We have been having this issue as well, its been driving me nuts!

I have filed a bug report to show this is still happening on Unity 5:

http://fogbugz.unity3d.com/default.asp?696648_7k16fb73qopnp2bp

 

This is happening for us in 5.0.2 - both in editor on mac and on some ios devices.

 

Is it happening on iOS?