Performance degradation coming from 2744 to 3067 or 3077

Solar2D Daily Builds and Public Releases
#1

Hi

We had to stick to Corona 2744 because it was the last one to support XCode 6.4. Recently we got a green light to upgrade to the newest XCode and so we did, updating corona to 3067. 

After the upgrade, we saw a rather large performance deterioration regarding version 2744. I didn’t expect it to be Corona, though it were the new version of libraries we used or just the change to XCode 8.

During gameplay, we heavily rely on physics, every half of a second we take a screenshot [not write it to disk, kept in memory], and we load another chunk of level definition. Not sure if it’s connected, but every few seconds [or often] there’s a few ms hiccup. It’s clearly visible, especially on iPhone 6 plus. This makes the gameplay stuttering and we just decided to move back to 2744.

Today, however, I have finished preparing the Android release and again, tried updating to the latest Corona. I was quite amazed to see the exact behavior. I was using my Galaxy S8 for testing - every few seconds or often there was a clear hiccup.

I have decided to try to substitute the new libcorona.so file with the one coming from version 2744. To no surprise - everything works perfectly fluid even on our old devices.

I am not going to go through all of the versions one by one now to determine when it happened because I don’t have time for this now, but maybe you would know what’s wrong. There’s a lot of performance to gain there.

We are trying to remove some of the functionalities we think could cause this, and that we can actually remove. I am quite certain it’s connected to the loading of chunks, but we will see.

Thanks

Krystian

#2

I asked Engineering for some input on this. But it’s such a huge range with over two years of changes and we will likely need a narrower target.

Rob

#3

I can narrow down it to last few months.

Currently: transitions are failing and slowing down a lot.

And other thing - sprites are slowing down too much.

I can make a example performance test scene - to show off my problem.

Rob, can you let me know if there any ongoing “transition” and “sprite” fixes and know bugs?

#4

Just a thought… could your hiccup be when GC kicks in?  Maybe that changed between versions.

#5

@efgames.net, we most certainly would be interested in a test case that shows your slowdowns. There have not been any signifiant changes to those areas recently. But I also don’t know what time frame you’re talking about. In the OP he was talking about going from 2744 to 3077. A lot can happen in that range, but we never plan to do anything that would lead to worse performance.

Rob

#6

I have a few test-cases for different problems. I`ll prepare and post them here as well.

First one is most easy one - https://forums.coronalabs.com/topic/69646-20173109-building-for-win32-duplicate-main-execution-bug/

Second one is sprites - I have a big atlases and small atlases - with small - all ok, with big ones - is not. I`ll prepare a simple test-project tommorow.

#7

We will also need to know more about the environment where this is happening? In the simulator? on device? 

What version of Corona?

Windows or Mac (and OS versions)

And of course the test case would be great.

For issue #1, lets keep it on it’s own thread and keep this to the slowness issue.

Rob

#8

Hey Rob,

I gathered a test scene: https://www.youtube.com/watch?v=6mlpxk9CdC8

  1. Problem - is a amount of frames in atlas. The more of them - the laggy it gets.

Maybe cashing indexes of frames in atlas is not used? ( or not properly, or lua specific issue - you know better)

(bug - amount of frames are slowing down too much)

  1. It lead to next bug with transitions - when it lagging like in example - transitions will stop responding, and onComplete will not be called as a result.

You can notice that molten metal is stop flowing at 0.25 here: https://www.youtube.com/watch?v=xcX7Ewv0f1c

If you like - I can make a test scene with that too as well. But I suspect you aware of this problem - since “transition” changes are in http://developer.coronalabs.com/corona-daily-builds/summary =)

(bug - “transition” is not reliable)

Should I make a another thread about them? Or this is something that is knowed? Or it is something that “is not important to fix this year”?

Since my games always on edge of CoronaSDK performance - would be great to know my limits here. Pity - I had to give up using “transition” for this project. As always - I`m using gameplay features to limit stuff on screen to control lag.

Here is a example of a game that I`m working atm(physics kicks in at 1:30): https://www.youtube.com/watch?v=OsoWGlmb5O8&feature=youtu.be&t=87

#9

Transitions are ok for simplistic animation but when you are talking about lots of animating objects the library is doing too much extra work per frame which slows things down.

For hundreds of objects you will definitely have to bin off transition library and do it yourself in enter frame to get decent performance.

#10

Can you explain this:

"But I suspect you aware of this problem - since “transition” changes are in http://developer.coronalabs.com/corona-daily-builds/summary =)

(bug - “transition” is not reliable)"

 

a bit better? 

 

Rob

#11

I use it for few things - when it failed at metal casting example - there are just two of them.

I use lot of sprites objects.

You suggesting me to write my own sprite library?

#12

I was going to say have you tried just using an enter frame event and using setFrame() for your animation? I have 500+ animations now running at full speed on mobile by ditching transitions and “doing it myself”.  This is on top of some 20k other display objects.

Number of frames (at least when changed manually, I can’t comment on sprite animations from the Corona side) should have no slowdown as it is a free operation as it is the same texture.

Regarding atlas size, generally the larger the better (try not to go over 2048x2048 as you will hit issues on older devices) as this has less draw calls.

#13

Bug it self or that transition is on chage list?

Bug - transition failing to call onComplete, if there is a lag in game. As Example - caused by too many sprites with too many frames on stage.

#14

Thing is - that 120 works fine in my test, but only if frames count is low.

Nope, I didnt. Should I? How many frames in your atlases(in average)?

I`ll try this today - using sprite.setFrame instead of realying on sprite methods.

#15

My largest one has 146 frames.  I use a few different atlases

Graphically, I am pushing a whole lot more through the open GL pipeline than your example and I can easily sustain 60 fps on simulator.  I limit to 30 fps on device to conserve battery.

My game size is roughly 9000 x 4500 px so only a percentage ever fits on screen.

#16

My smallest one is 150+, biggest is 300+.

I tryed to run my test without sprite:play() - and it is same results. Weird!

Are you using display.newSprite? Or you wrote totaly your own?

Can you take a look at my testScene?

https://www.dropbox.com/s/zzilcwjpgbncs31/TestWin32.zip?dl=0 (currently with commented sprite:play() method)

I`m now extracting your APK to check your atlases. =)

#17

Your performance degradation is coming from your shader (and the fact that everything is global!).  Global is some 30% slower than local.

Comment this out and I get 1000 sprites at 60fps solid

There are plenty small little optimisations to be made but the shader is your killer here.

Hope this helps.

#18

Indeed. That is my killer. Tnx!

This is a just a test - it is not a game sources =)

I would like to have a option to redraw them in real time. Or atleast at loading stage - like duplicating atlases with shader on.

Then for gameplay I guess I have to display.save() atlases with shader already applied to them.

#19

Tnx!

I resolved my problem with lag - https://www.youtube.com/watch?v=o6v0TCiX8kQ&feature=youtu.be

By prerendering atlases with applied shaders before using them in “display.newSprite”.

#20

I asked Engineering for some input on this. But it’s such a huge range with over two years of changes and we will likely need a narrower target.

Rob