Severe jittering / "blurring" when scrolling

Help
#4

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?

Thanks!

#5

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 =)

#6

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:

http://www.joshuagranick.com/test/JitterTest.zip

#7

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.

#8

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:

#9

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

#10

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.

#11

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: https://dl.dropboxusercontent.com/u/18504814/JitterTest.zip

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).

#12

@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

#13

@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.

#14

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

http://www.gamedev.net/topic/649791-stutter-micro-stutter-even-w-vsync/

1 Like
#15

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

#16

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:

#17

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

#18

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?

#19

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
#20

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

#21

I don’t know if it’s related, but I was getting some little “jumps” with some moving image on android at 60fps, and after searching on google I’ve found an old issue that was resolved, but I gave it a try and set < window fps=“61” / > instead of 60 and those jump seem to have gone.
I didn’t have a lot of time for testing, but for what I’ve seen it seems that a frame is completely skipped once in a while (something related with vsync or buffering?), because I didn’t get any delta time greater that 1/30s between frames, so I guess ENTER_FRAME was processed but the frame didn’t get to the screen.

It’s a OpenFL legacy project on an Galaxy Note 10.1 2014 with Android 4.4.2

haxelib list: 
hxcpp: [3.1.68] 
lime-tools:  [1.5.7] 
lime:  [2.1.3] 
nme: [5.2.13] 
openfl-html5:  [1.4.2-beta] 
openfl-native:  [1.4.0] 
openfl-samples:  [2.2.2] 
openfl:  [2.2.8]
#22

Hey guys!

I know that this is fairly old thread, but i’m currently struggling with exactly similar problem that’s described in this thread. So i have a question, was this problem ever solved or not?

#23

Are using next or legacy? I think you dont have this problem in next