Severe jittering / "blurring" when scrolling

I have been experiencing this problem for a while in HaxeFlixel and recently i tested OpenFL to see if the problem would appear there also.

Turns out the exact same problem occurs when doing scrolling in pure OpenFl.

This affects neko and cpp targets as far as i know.

I posted a demo showing the problem here:

There are two projects there, one for HaxeFlixel and the other OpenFl.

I wonder if am i doing something wrong or is this a problem in the core rendering system?

If this is indeed a bug in OpenFL it is a very serious one - any scrolling, even in very low speeds presents this “blurring” in a very perceivable way.

Is anyone having the same problem, either in the demo above or in your own projects?


1 Like

Does it make a difference if you enable vsync?

Unfortunately no - the problem happens with vsync on, enabled through project.xml:

<window width="1280" height="720" fps="60" background="#000000" hardware="true" vsync="true" />

Disabling it has no effect in the problem, it only makes the jittering more noticeable.

In the demo i’m listening to the ENTER_FRAME event and using delta time to calculate how much to move the sprites each frame. I also tried to use a fixed amount but nothing seems to solve this.

I’m making an endless runner game, which relies a lot on scrolling, and even at low speeds this problem affects the visuals a lot.

I really wanna get rid of this - all OpenFL projects will look a lot better with real smooth movement. Any idea on what might be the cause of this?

Thanks a lot!

I updated the demo showing the same scrolling problem using Bitmap, Tilesheet and OpenGLView classes. Also now there are controls to toggle between delta time and a fixed position change factor.

Could someone test these demos in Windows platform and confirm if the jittering also happens in your machine?

It is happening for me in all machines i tested so far, with different video cards / brands (Intel, Nvidia, Ati) and different versions of Windows (7, 8, 8.1). Here is the demo url:

My main concern with this is to know if this something wrong i am doing or is it really a bug in OpenFL (or Lime).

If this is a bug i’m surprised the little attention this is getting so far since it would affect any game with scrolling or fast repositioning of DisplayObjects.

Anybody with the same problem? Any fix or workarounds available?


I have seen this problem for a long time, and I find it in neko and windows, flash and android are jittery free. The Fps shows you 60fps all the time, because it accounts the number of frames in one second. But if you graph the individual deltas you can see the jumps, and they happen at regular intervals of times.

Now the interesting part of this “bug” is that if you increase the workload the bug disappears, and sometimes it appears back. If you can’t reach your target framerate you never see this problem.

I’m going to look at how openfl manages the update. I think the porblem is that OpenFl or Lime wait too much at some steps, and then they try to catch up. Maybe its a Windows related problem.
Let’s see if we can fix it =)

I just tried doing a Lime-based test, and it seems like the frame timing may be better. If I focused on the animation and ignored the moire, I did notice that sometimes it did feel slightly jumpy – not fully consistent in frame rate, before, but seems smooth with this sample

Please feel free to give this a try:

Hi guys,

@juakob I think you’re right - i noticed the differences in dt varying in machine from 0.015 to 0.022. This probably causes the “jumping” behavior.

@singmajesty Yep, there is the jumping problem, but what i am actually concerned about are the “micro-jittering” (i don’t know how to explain it better). Notice the vertical lines in the image cannot be seen correctly when moving - it’s as if they are constantly shaking, creating this “blurry” effect.

The perceived moire pattern effect appears to be related to this, it seems that the pixels move back and forth between positions between frames, as if a subtle displacement is taking place.

Some users have related this is headache and / or dizziness inducing.

I really have no idea to the root cause of this, but as @juakob said it seems definitely related frame-to-frame updating.

That said i am really commited to work on solving this severe problem. I think it can be a huge deal-breaker for a lot of possible and current users.

After testing @singmajesty’s demo in Lime it seems the problem is there instead of in OpenFL.

Besides testing in Windows i also tried it in Android (OnePlus One running Cyanogen 11.0 (KitKat 4.4.4)) and the moire pattern / jittering / blurring is still there. I cannot test in iOS currently, if anybody could try it would be great.

I’m still a layman in Lime and i know very little about the API, but if i had to guess i’d say that the problem could be in GLRenderContext or even in the GL class (i’m currently looking at the lime_gl_draw_arrays native method).

I’ll update the post if / when i discover anything - any help with this would be very much appreciated! :smile:

Hi, I added a graph to be a little more accurate on detecting jitter update code

on the top right you can see the delta between frames, the red line is the optimal delta (1/60) the light blue is the actual delta

In flash you get this

In neko you get this

The delta is so jumpy that using it makes the simulation even worse, because you are using the delta from the last step and assume that the current step is going to run at a similar frame rate. Here you are always using the wrong delta, so that must increase the jitter.

Yeah, using dt increases the problem, however using a fixed dt does not fix the problem.

Take a look at this slight modification of Joshua’s test:

It starts without deltaTime, instead using a value of exactly 1/60 each frame. I tested “flooring” the values before rendering also with no luck, use enter to toggle (also same results using fround or fceil).

@Tiago_Ling you should look at when Event.ENTER_FRAME it’s propagated, because I think enter frame it’s not been call at a consistent rate, maybe the thread goes to sleep for too long. I’ll try to look at it tomorrow

@juakob I think the problem is at a lower level - i tested Joshua’s example which uses pure Lime and OpenGL and the problem is still there.

It could be something in native code even. I stopped looking when i reached the ndll calls in Lime.

The problem is not in HaxeFlixel and not in OpenFL, but in Lime.

By the way, thanks for the help guys, i’ll be actively looking for a solution or workaround at least until we discover what is in fact happening.

This might also bring some useful information into our case (SDL):

1 Like

I wonder if buffering would make a difference, not sure if we’re double buffering or not

Can i change this through project.xml?

I noticed there are the window options depth-buffer and stencil-buffer, but i tried changing them without any noticeable difference.

I will make more tests just to be sure, but if there is another way to set double or even triple buffering directly in OpenGL please let me know. Thanks! :slight_smile:

Looks like SDL_GL_SetAttribute(SDL_GL_DOUBLEBUFFER, 1);, but it says that it defaults to on

Is there c++ code that gets called directly from lime.ndll?

I saw some .h and .cpp files inside lime/legacy but i don’t know if they are still relevant.

Do you think it might be something like this or everything related to this problem is inside Haxe files exclusively?

If it’s a Lime project (Lime 2) then it’s under “lime/project” and is probably simpler to wade through. Otherwise it probably is Lime legacy (Lime 1 / NME) and is under “lime/legacy/project”

1 Like

Just updated the repository with more test cases. Also made them simpler: