Very poor performance on MAC/PC builds. Test project included

Solar2D macOS Desktop
#1

We’ve been trying to port one of our scrollers from mobile to PC. The android and ios versions work flawlessly but getting the scrolling to be “smooth” on desktop has been a nightmare and during the last 10 days, we’ve tried every trick in the book to resolve the choppy scrolling and tested across 10-15 different systems (mac+PC) to no avail. 

My colleague had posted regarding this on the forum but that was never going to be very helpful as the source to the game in question is massive so providing snippets and requesting help for that particular project will be a waste of everyone’s time. 

I am now enclosing a zip folder with a very simple, minimal scrolling project. There are a total of about 5-6 display objects that are pre-spawned and then being scrolled endlessly. This is all being done in the main script and I’ve added comments to explain what’s going on.

We’ve tried compiling mac and PC builds for this and the performance is still not acceptable with the objects jumping to their updated locations rather than scrolling smoothly. On even the most low-end mobile devices, this project works perfectly with no stuttering. 

I’d appreciate if someone from the corona staff could please give this a go-- we are at a stage where we are trying to get serious about our business and have recently lost a client who terminated their agreement with us after what’s been going on with 64-bit Android builds and our new desktop game is queued for crowdfunding and we can simply not proceed unless we find a solution for this problem.

Thanks in advance.

#2

Seems fine on my MacBook Pro (Retina, 13-inch, Late 2013). Although a bit choppy when running on Windows 7 in Parallels.

On an i7 32gb Windows 10 machine with GTX 1060, it runs smoothly although not so much in the simulator.

I’m on Corona version 2019.3474.

Just downloading the latest daily build onto my work machine which only has integrated graphics - it’s taking ages so will report back later.

#3

It’s a tiny project and sometimes it can be a little subjective-- you might be able to see it if you are able to make a quick Android build and then compare it with your Mac build. 

I’ve tried running this in the last 30 or so minutes on a MBP 2015 OS HighSierra, 2 IMacs (2012) OS HighSierra, A Lenovo Win 8.1 AIO (i5, Nvidia 800a), HP laptop Win 10 (i5 , intel HD), Toshiba Ultrabook Win 7 (i5, SSD) and it’s been quite choppy on all these devices. 

All have at least 8GB of RAM and authentic OS installations. 

Extrapolate this to a much bigger project with faster scrolling, animations, particle effects etc. and it becomes unplayable…

#4

Tried it on the HP Laptop - it’s i7 16GB but integrated graphics. Agree the performance is terrible. Integrated graphics aren’t completely useless anymore and should be able to handle what you’re doing no problem. Certainly I see much better performance from Unity games on similar machines.

#5

I had posted regarding this issue earlier but then eventually deleted. @Rob could you please have a look at this and perhaps link us with one of your technical staffs. This is a rather serious issue and given how things are we can’t publish games on steam.  

#6

I ran the test project and built it as a MacOS app. I have a new MacBook Pro 15" 2018 2.6GHz i7 with 16gb of ram, dual GPU with a Radeon Pro and Intel UHD.

The performance was quite smooth in the simulator and I saw identical performance running the built MacOS app. I don’t see any chop at all. I’ll try it on a fairly low in Windows machine in a bit.

Rob

#7

Yes, please do that, Rob. We are typically not quick to post on the forum and do our absolute best to examine the code, optimise it and use best-practices all throughout to achieve good performance and we’ve been working for a very long time on Corona. 

There are three individuals on this topic who already claim to have experienced low performance with what’s nothing more than a tiny demo project so I have to say that the problem is quite real and if we are unable to fix this, our project-- which we started in December of 2017-- will be dead.

The game that we are unable to run properly on Desktop has over 150000 installs on Android + iOS and there were never any performance issues on mobile. 

We are, quite frankly, desperate for some help.

#8

short answer is:  your delta time is not precise enough.

long answer:  how well a delta time approach (as you use) works is entirely dependent on how “good” the system timer is.

most c libraries (upon which lua is built) query a hardware timer that (on PC’s) has a resolution of 1/64 sec (15.625ms).

(most “real” Windows games, ie native code, typically use a much higher precision performance counter w nsec resolution)

i’ll let you work out how well 1/64th resolution ticks would line up with a desired 30 or 60 fps framerate.  (hint:  it’s not good)

but it’s worse than that, because even THAT resolution isn’t guaranteed - it may only be 10ths of seconds, or whatever OS resets it to.

to “prove” it to yourself:  query the timer rapidly in a tight loop, notice all the duplicate values??  that’s your problem.

for i = 1,100 do print(string.format("%f",system.getTimer())) end

i don’t know exactly what results you’ll get on your system(s), but you’ll probably see a fair degree of “precision” (how many ‘significant digits’ are reported) but not much “resolution” (how many unique values are returned at what frequency).  google it, well-known problem.

#9

I ran it on an older Lenovo laptop and it was choppy, but it was also choppy in the simulator. I didn’t see much of a difference between the two.

Rob

#10

I don’t know the configuration of your laptop but do you reckon this project should be choppy on your device? I can confirm that I see the choppy scrolling on our simulators AND desktop builds but never on mobile builds.

For the test project, I’d imagine this is something that any device that can run the Corona simulator will be able to handle, no?

#11

It says it’s an i7-5600 @2.6ghz with 8gb of ram but I’ve had it since at least 2014 and it has a terribly small hard drive. so I could be swapping a lot.

It seems like the more it runs the better it gets, but it’s not as smooth as it is on the Mac. Task Manager didn’t show any stress going on with regards to memory, gpu, disk etc. But keep in mind, Corona/Lua is single threaded and my Lenovo CPU is considered a low power CPU, so it’s not.

It’s possible depending on the Android device, that it’s faster than the PC you’re running on.

#12

davebollinger: if the issue is the delta time calculation why is the same stuttering visible when you remove it and just move everything by a constant value per frame? We shouldn’t be getting framedrops on such a simple project, no matter the machine.

#13

This.

The first thing I had done during testing was to take delta out of the equation and hardcode the value of translation. Speeding up or slowing down of the scrolling behaviour, as expected, was present, but the stuttering was still there and it is clearly nothing to do with how it’s been programmed. 

@Rob, any chance you can please have someone look into this at least briefly? I think it’s only reasonable to expect such a simple project to work without these issues on most machines.

#14

64-Bit Android is the priority. I’m not sure when we will have to time to look at this. I’ll put it on the list. But if I’m being honest, the queue of higher priority updates will not bubble this up any time soon. Corona is open source. So this is something I think the community can grab the source and see if they/you can find the problem. 

Rob

#15

i doubt that the choppy/stutter/jitter you’ve described is an actual dropped frame, rather it’s just inconsistent per-frame timings.  imagine one frame at 28fps, the next at 32fps, repeat - your AVERAGE framerate still works out to 30fps, but a fixed motion per-frame will appear jittery.

corona ITSELF is subject to the same hardware timer limitations - it’s frames are NOT perfectly 30fps.

i haven’t checked source but I’ll bet you it’s using an api like GetTickCount() or equivalent, which is totally inadequate for this use.

issue is:  fixed-motion with varying frame times - but whether you attempt to fix it via the first (dt motion) or the second (try to make frame-time fixed by sleeping dt), it just doesn’t matter if you can’t accurately calculate dt.  they are literally “reciprocals” of the exact same problem, and neither can be fixed without a better timer.

probably the best fix would be a native plugin for the QueryPerformanceCounter api then use THAT to calculate your dt for motion (it’s the easier route, since you can’t apply it to the frame rate dt without recompiling core - a way bigger task).

#16

I’ve never understood why frame rate was so wildy inaccurate but 1/64 resolution would certainly explain it.

Frame rate using enterFrame is +/- 25%

#17

It’s a shame that there is no straightforward way to cope with this-- my research over the last two days shows that this is obviously a phenomenon that is also seen in other engines like Unity etc so I’m not blaming Corona per se but just a little frustrated that there’s no workaround.

Clearly it’s not a performance issue as there are plenty of threads here dating back to 2014-15 regarding the stuttering even when trying to move a single display object across the screen but there doesn’t seem to have been a proper resolution so far. I confess I don’t have detailed knowledge of how these things work at the low-level but not having API access to more advanced features only makes it harder. 

#18

i’ll restate that a native plugin for QueryPerformanceCounter (on Win) and whatever it’s equiv is on OSX (mach_absolute_time?) would probably be easiest solution.  (that is, unless you have the clout to convince corona engineering to build equivalent into core)

baby steps:  the whole problem with a delta time correction in dev’s lua code, is that it must presume that it can do a “better” job of tracking time that corona internals which already attempt to calc delta time in order to deliver a stable frame rate.

iow, if corona itself could calc time precisely, then it could deliver precise frame rates, right?  (and you wouldn’t even need to worry about doing your own delta time correction in that case!)  but it can’t, so it’s folly to think that a dev’s lua code is going to do any better than corona internals, given roughly same quality timers to work with.

nyquist theorem will support that you need at least double the clock rate to reliably approximate a frame rate, and even that is barely enough, would just achieve an “average” of that frame rate, with significant jitter - and that’s what happens on Win builds now.  but what you really want is to precisely hit the “rising edge” of that timer signal, to get a rocky-steady frame rate, so you’d need your timer to be several orders of magnitude “finer” than your frame rate*, and GetTickCount (on Win) is NOT going to achieve that.

* (basically needs to be at least double your tolerance for a _single _frame’s timing, fe if you need your frame time to be 16.667ms +/- 0.01ms, then you need a timer of at least 0.005ms resolution, while GetTickCount is something like 10-17ms resolution)

#19

Well, I’m not sure about the rest, but I find this interesting and I’m learning a lot. Thanks @davebollinger! :smiley:

#20

Delta time will only correct for dropped frames/long frames.  It will not fix something inherently broken in the core.

It is a bit ridiculous that this is even a thing.  If you set 60 fps you’ll get frame times between 12 and 20 ms.