I would welcome and support that. I am really interested what the corona engineers might have to say about this.
Great by all means add any links you have found on the subject and I will do so shortly.
On a side note i had a discussion with walter about how the corona frame loop actually works and the way it is setup now, your own frame events and transitions will make the already existing choppiness worse even if they take less than the time between frames.
I don’t know how other engines handle this but in my mind it would be better if the enterFrame events (which handle timers and transitions as well) happened imediately after the screen update with the expected time of the next frame passed as event.time. I think this would eliviate the choppiness that your own app code creates. I may be wrong here, as I don’t know every thing that’s going on in the background. Currently Corona updates screen then waits for next frame time while handling the user events and only when it’s time for the next frame calls enterFrame listeners. Now if the enterFrame listeners took a consistent amount of time that would be fine, but if the time varies from frame to frame then you get choppiness that is even worse than the one already comming from the engine itself.
Threads with this topic:
First the one i already mentioned http://forums.coronalabs.com/topic/45161-is-it-possible-to-create-smooth-movement-of-objects-across-screen/
http://forums.coronalabs.com/topic/22327-how-to-achieve-smooth-animations-or-transitions/
Very old post about the issue where walter actually mentiones the culprit that was apparently fixed in iOS but not on Android. I think this is the same issue that still exists on Android and both simulators. I don’t have an iOS device to test this. Suppertap mentioned it’s smooth in iOS so this may be it:
http://forums.coronalabs.com/topic/749-corona-cant-keep-a-smooth-30fps-animation-useless/
http://forums.coronalabs.com/topic/15520-jerky-scrolling-graphics/
http://forums.coronalabs.com/topic/44783-choppy-performance-when-moving-image-across-screen/
This thread talks about this issue and another that is a scrollView problem and is not pertinent here
http://forums.coronalabs.com/topic/42131-in-g2-scrollview-is-not-that-smooth/
Enough?
I’m sure there’s more but i have things to do.
Thank you for this. Great work! 
Any thoughts on this from the staff? Is it really not possible to address this on android and simulators?
I am dealing with the same issue… Corona staff, please let us know about your thoughts on this!!!
I filed a bug report linking back to this post so I’m surprised if nobody has seen it!
Can you post the bug report number here please?
Thanks
Rob
Hi Rob Case 31364
Okay thanks! Engineering hasn’t had a chance to look at this yet.
Rob
Any news on this?
Had a similar problem I mentioned here: http://forums.coronalabs.com/topic/45787-why-has-graphics-20-killed-my-frame-rate/?hl=%2Bframe+%2Brate
Alright so picture in your mind the latest flappy bird clone but please keep reading…
Originally I used transition.to for the floors and pipes and it works very smoothly on iOS. However when I built it for Android it had a tendency to be very choppy randomly on certain hardware. I tried a lot of things, and eventually decided to switch to an enter frame listener. Slight improvement but still randomly choppy. I then aded a delta time calculation into it to try and compensate but again still very choppy.
I also tried a pre graphics 2 build - slight difference but still unacceptable.
So then I decided to go back to basics and set this project up.
Config file:
application = { content = { width = 320, height = 480, scale = “letterBox”, fps = 60, }, }
main.lua:
local maxX = 480+((display.pixelHeight * display.contentScaleX) - 480)/2 local minX = 480-((display.pixelHeight * display.contentScaleX) + 480)/2 local floor = {} for i = 1,5 do floor[i] = display.newRect(0,0,100,100) floor[i].x = maxX+200*(i-1) floor[i].y = 160 end local endPos = minX-floor[1].width local runtime = 0 local gameSpeed = -3 local function floorControl() local function getDeltaTime() local temp = system.getTimer() local dt = (temp-runtime) / (1000/60) runtime = temp return dt end local dt = getDeltaTime() for i = 1, #floor do floor[i]:translate(gameSpeed*dt, 0) if floor[i].x < endPos then floor[i].x = floor[i].x+1000 end end end Runtime:addEventListener( “enterFrame”, floorControl )
Again I built for the device and even moving these 5 rectangles across the screen is far from smooth.
So I added the loq_profiler lib into the code and I notice that randomly the frame rate drops from ~57 fps to 40fps then jumps back up. Why?
The two devices in question are a samsung galaxy s2 tab and and an icoo D70 pro tablet. Both showing similar drops in frame rate randomly. In fact with a static rectangle the samsung device was dipping down into the 40’s too.
On other hardware like Galaxy S3 and HTC Desire S things run a lot smoother.
Is this a limitation of Corona, a Corona bug or am I doing something fundamentally wrong?
Opinions welcome.
Have you profiled your code? I see a lot of room for optimization in floorControl, and since it’s called every frame, you should optimize it.
@davemikesell No I didn’t actually. Once we got to the point that having 1 static rectangle on the stage and the frame rate dipping 20 frames then I posted this.
I’d be interested to know your ideas for optimising it actually for future reference.
Actually, not sure changes are going to buy much - I did some testing and I think the function call overhead on enterFrame is probably dwarfing any tweaks I would make. But in general, I’d make getTimer local (local getTimer = system.getTimer), recalculate the 1000/60 in a constant, and assign floor[i] to a local in the loop so I didn’t dereference it multiple times.
Anyway, I’d grab Profiler.lua (can’t remember where I got it) and do some profiling if you haven’t already.
Hello, Is this still being looked into? Seems like a while since the last post.
Hello, Is this still being looked into? Seems like a while since the last post.