jerky / hitchy / jittery scrolling under Windows, iOS

[matthew.franklin]

I'm working with a really simple case:
* create a tile deck
* instantiate a couple dozen fairly large sprites from it, put them next to each other
* set the layer's camera
* call camera:moveLoc over 10 seconds or so

It will noticeably hitch several times a second.

I've tried replacing the camera:moveLoc with an update coroutine that moves the cam a fixed # of pixels per call, or a # multiplied by device time, or a # multipled by elapsed time, with no improvement in result.

I've cleared and set a variety of loop flags, pretty much every possible combo.

On Windows, modifying GlutHost::_onPaint to get a glFinish at the end smooths it significantly:

[code=C++]static void _onPaint () {
AKURender ();
glutSwapBuffers ();
glFinish();
//glFlush(); -- doesn't improve anything, only glFinish works.
}
[/code]

Adding a similar call on iOS does not help, leading me to believe the glFinish simply hides a bug involving the update loop elsewhere.

Does anyone else have a nice, smoothly scrolling background? This is such a simple repro case, I find it hard to believe it's something strange I'm doing in my program. OTOH, on initial examination of the MOAI update loop, I didn't find anything obviously wrong-- it's also fairly basic, just running sim steps to catch the sim up to system time.

[Mud]

The developers seem to have a lot on their plate. I imagine it would save them time when evaluating this if you could post a minimal sample that reproduces it.

[matthew.franklin]

I'll post one later this weekend. It's pretty much what I wrote, but I'm not at a computer where I can code just this minute.

[matthew.franklin]

Alright, here we go.

Hitchy on multiple PCs, iPhone simulator on a Mac, and a couple iPhones.

Code: Select all

1.  


2. local screenWidth, screenHeight = 960,640


3. MOAISim.openWindow ( "scrolltest", screenWidth, screenHeight)


4. local viewport = MOAIViewport.new()


5. viewport:setSize(screenWidth, screenHeight)


6. viewport:setScale(screenWidth, screenHeight)


7. viewport:setOffset(-1, -1)


8.  


9. local tex = MOAITexture.new ()


10. tex:load ('pixelletters.png')


11. local deck = MOAITileDeck2D.new()


12. deck:setTexture(tex)


13. deck:setSize(1,1)


14. local w,h = tex:getSize()


15. deck:setRect(0,0,w,h)


16. local layer = MOAILayer2D.new()


17. layer:setViewport (viewport)


18. local camera = MOAITransform.new()


19. layer:setCamera(camera)


20. MOAISim.pushRenderPass (layer)


21.  


22. for i=1,10 do


23.         local sprite = MOAIProp2D.new()    


24.         sprite:setDeck(deck)


25.         sprite:setIndex(1)


26.         layer:insertProp(sprite)


27.         sprite:setLoc((i-1)*w,0)


28. end


29.  


30. camera:moveLoc(10000,0,20,MOAIEaseType.LINEAR)


31.  

[plamen]

yeah, i was about to post same observations but on PC host. I expected it to happen only in simulator but not on actual IOS device. I dont know what to do with my project now. if its not working smoothly on IOS/Android.

[mikegriffin]

PC -> has the hitching judder
Android -> has the hitching judder
Ipad -> runs completely smoothly

How much better is the performance on Windows - it may be worth exploring building libmoai.so for Android using glfinish......

[matthew.franklin]

On Windows (on the system I was using-- could vary between hardware), it got a LOT better with glFinish. But it got no better when I did the same to iPhone. So possibly it was just random luck, in that glFinish caused the timing to more closely match between wall-clock per frame and sim step per frame.

[ibisum]

I'm not seeing a lot of jitter on Android, but I am on testing on fast devices, mostly. I must say that the GC issue on Android infects not just MOAI but other GL engines, also .. there are certain things that can be done to tune the use of GC for graphics properly on Android, and either a) MOAI team have done it, b) haven't done it yet, or c) something about your test rigs is odd?

[matthew.franklin]

The jitter I'm discussing is not due to GC. It happens multiple times a second. I breakpointed in the GC code, and it isn't happening with that frequency. (Which is good, given the code. 3 times/second GC on this sample would be insane.)

And it's not my test rigs, which are wildly divergent hardware with nothing in common except for the fact they use transistors.

[mikegriffin]

There are definitely timing issues for Windows and Android
see post2194.html?hilit=judder&sid=d3032b75f9bc5dfb7b8704fc00f074a1#p2194

Increasing the the sim step size helps in this case but not the code above.

[patrick]

I'm running the code on my system now and am seeing the hitch you're talking about. I am seeing it in both debug and release builds. glFinish didn't make a difference on Windows for me.

Both the GLUT and Android host use timers to trigger redraws. There isn't any notion of a proper v-sync in these hosts - just set the timer to 60hz and pray. So if we get two updates in a frame or miss a frame we're going to see a hitch pretty much no matter what. The iOS host uses the DisplayLink API, which I believe is synchronized with vblank. This would explain the smooth(er) behavior on iPad.

So... this is something that needs some research. We won't be able to get to it internally until after 1.0, though I recognize it as a major problem for those of you developing on Android and desktop.

I strongly suspect the timer-based implementation is to blame, but don't have a smoking gun. If anyone has time to either figure out how to implement v-sync in the existing hosts or set up a new host I'd be really interested in the results.

[ibisum]

DoubleBuffering + GLFlush() -> GLFinish() == possible solution?

http://stackoverflow.com/questions/5890 ... -in-opengl

Also of interest, what is reported here:

http://gamedev.stackexchange.com/questi ... on-android

"interval is silently clamped to minimum and maximum implementation dependent values before being stored; these values are defined by EGLConfig attributes EGL_MIN_SWAP_INTERVAL and EGL_MAX_SWAP_INTERVAL respectively."

Perhaps these can be tweaked in the Android host for fun and profit?

EDIT: Another interesting solution of the problem for Android - self-cooked vsync:

http://quirkygba.blogspot.com/2010/10/a ... -in-c.html

[mikegriffin]

It would be really useful to find the "smoking gun" as this issue has been frustrating me for over 2 months now.

I think it's more important to solve on the android platform (as moai is "sold" as a mobile framework) than windows but they are related some how.

[mikegriffin]

I don't think this is a vsync issue.

I installed
http://www.opengl.org/sdk/tools/gDEBugger/

You can debug an exe at each call to GL.

and stepped through the code above on Windows. Where the "judder" appears you can see a physical jump (ie moai is telling GL to draw the buffer but rather than moving at a fixed step for example 2 pixels each time the jump suddenly goes up to 15 pixels)

This points it back at timing... or some sort of attempt to catchup

So Moai is saying to gl -> move 2 pixels, move 2 pixels, move 2 pixels, move 15 pixels, move 2 pixels

Why it is doing this I don't know... is it processing lua and then resampling where layers, objects should be?

[patrick]

@mikegriffin That's right. If we miss an update due to timer slowdown then Moai will perform multiple sim steps (if 'spin' is allowed on MOAISim). You can prevent this and force MOAISim to perform a single, fixed step every time if gets an update... but then then if the timer slows down we'll see the opposite problem - a freeze or lag. The 15 pixel change you're seeing is due to multiple sim steps being processed between draws. Check out MOAISim.setLoopFlags to modify the behavior.

[matthew.franklin]

Just to verify, I've re-run the sample code on the following platforms:

* 3 different Windows XP PCs, using moai-untz.exe
* A core i3 Mac, using iPhone Simulator
* An iPhone 3GS

(Haven't run on an iPhone 4 or Android, as I don't have one handy right now.)

All of the above demonstrated highly noticeable jerkiness / jitter / judder / (whatever term we're using now) in scrolling.

[mikegriffin]

I'm pretty sure I played with all the SIM loop flag options with no obvious difference. I'll revisit to confirm.

If the flags are not making any difference I'm beginning to wonder if the flags are being honoured correctly.

Is there any other place frames would be dropped? In the renderer somewhere?

My preference would be for a slowdown or freeze rather than a "SPIN"..

The SIM and the clock shouldn't be going too far out due to performance (ie physics, too many sprites, too many graphics, audio) because the "jitter" appears on a very basic programme (ie 2 sprites with 1 moving - no physics)

[mikegriffin]

OK

I have tried all these flags (ie MOAISim.setLoopFlags ( MOAISim.LOOP_FLAGS_FIXED) )

LOOP_FLAGS_DEFAULT = SIM_LOOP_ALLOW_SPIN | SIM_LOOP_LONG_DELAY;
LOOP_FLAGS_FIXED = SIM_LOOP_FORCE_STEP | SIM_LOOP_NO_DEFICIT | SIM_LOOP_NO_SURPLUS;
LOOP_FLAGS_MULTISTEP = SIM_LOOP_ALLOW_SPIN | SIM_LOOP_NO_SURPLUS;
LOOP_FLAGS_SOAK = SIM_LOOP_LONG_DELAY | SIM_LOOP_ALLOW_SOAK;

LOOP_FLAGS_FIXED offers the smoothest performance but the "JUDDER" is still there!!!

[plamen]

Some additional observations on Windows host.
I use IntelliJ IDEA IDE. For some reason the console of this IDE is not refreshed in real time as it happens when i start MOAI host from normal windows console (cmd). When i use print statement (for debug reasons) i receive results with big delay sometimes when i close the host. But!!! Jittering behavior is noticeably less than when i start same project from windows console. Hope this can give some additional help on this subject.

[adam]

Looked at this for a bit, our observations:

Each platform seems to be a different problem.

On iOS, the issue seems to be the sim stepping more than once per frame. We'll have to go over the budget calculations a little closer to see the problem, you can change the loop flags to fix this though. ( To any that only do a simple step, so boost/fixed, not spin. )

On Android there seems to be a larger issue. First several of the devices we have seem to have lock on the buffer swap at 30 and 60fps. This results in the frame time jumping from ~16ms to >33ms every few frames, so even setting different flags won't help. My only thought here is to lock the framerate to 30 Fps on android devices that can't maintain 60. Double checking with some very basic OpenGL samples today, but even with nothing rendering we noticed the framerate would not stay at 60.

Haven't looked at PC/OSX close yet, but its probably something similar to the above.