Redraw stops on iPad

Solar2D General Questions/Discussion
#1

Hi all,

I’ve got an issue that has me stumped.  I have an Android game published that is doing well.  Now I’ve managed to borrow a mac I am trying to publish on app store.  But I’ve run into a show stopper!

I use drag/pinch/zoom in my game and this works great on Android and in simulator (both pc and mac) but grinds to a halt on iPad. If there are any active transitions or animations on screen then they stop dead too whilst my finger is moving on the screen and carry on after after phase = “ended”.  

My onTouch is a runtime event and is a variation on the sample project as it handles dragging as well.  On sim and android my onTouch event takes 0.02 - 0.05s to run (depending if dragging or zooming or both) but on iPad it is taking at least 0.13s and my onFrame doesn’t fire at all whilst in drag (unless the drag is really slow).  What could account for the massive difference in performance?

With minimal assets the texture memory is only 10mb and with no dragging the fps is a solid 60 on iPad.  I am using 480 x 800 zoom even.

Thanks

Adrian

PS: I have a minor issue with notifications on LG G3 (1440 x 2560).  On the notification bar I just get a white square and when I swipe down I get a small icon in a round white circle.  I have both of these in my project IconNotificationDefault-xxhdpi-v11.png and IconNotificationDefault-xxxhdpi-v11.png - same as https://forums.coronalabs.com/topic/52166-large-notification-icons-on-android/

#2

I have managed to isolate this behaviour by modifying the sample pinch zoom… It is when you drag/pinch/zoom a display group with lots of nested graphics.  This doesn’t happen on Android.  

How to I send you a sample so you guys can see it?

#3

Hi @adrianm,

Dropbox is a popular way to share files… just zip up the project and post it there.

Thanks,

Brent

#4

Hi Brett

A use case is here http://www.spheregamestudios.com/ipad_issues.zip. works just fine on android and sim but not ipad/iphone

Thanks

Adrian

#5

Hi Adrian,

This seems to be some issue in your code. It appears that you’ve based this project on Corona’s “PinchZoomGesture” sample, but you’ve added a lot of unnecessary complication to it, as far as I can tell. I just took that same sample base and added your giant “grass” grid into it, instead of the single stock “aquarium” image, and I named the overall display group for all the tiles “background” (although you could rename this as needed). This group (“background”) is then used as the touchable object, not the Runtime.

I then installed the app on my iPhone and it’s quite smooth when I pinch-zoom in and out. In contrast, I installed your sample on the same iPhone and it’s very slow and clunky. So, there’s some issue in your code, and it’s not a Corona issue.

Hope this helps,

Brent

#6

Hi Brent

Thanks for looking into it.  I’ve isolated the problem further and I do believe it to be a Corona issue.  If I insert the grass tiles directly into the background display group then you are right, the speed on device is fine.  But, if I insert the grass tile into a new display group and then insert that into the background display group then it is unusable on iPad/iPhone.  However, this massive performance degradation does not happen on Android devices.

Could you please make that minor change to your test code and you will see the issue.

Thanks

Adrian

#7

Hi Adrian,

I used display groups within a larger display group and the performance is just fine, so it’s still something in your code. I’ve attached the “main.lua” file that I used for testing on my iPhone5 (didn’t test on iPad but the results shouldn’t be vastly different… if anything, it should be faster depending on which generation of iPad you have).

Note that this demo only shows pinch-zoom, not x/y scrolling, but I see no reason why the performance would degregate for scrolling.

Brent

#8

Hi brett

I see your main.lua does indeed perform fine on pinch zoom on iPad 2. So therefore it must be down to the touch event but i cannot see why yours performs so differently to mine when they are so similar.  Can you see anything in my touch event that might cause the massive degradation compared to yours?  I need the touch event to pan as well as zoom as this is quite standard for games.

Can you get your sample to pan as well as zoom?

Thanks

Adrian

#9

You were right… There was some bounds checking at the end of my touch event.  For some reason that ground performance massively on iPad v Android.  I commented this out and iPad runs just fine.  Now to work out why this effected pan/pinch/zoom when it only fired on phase=“ended”.  Something is not quite right with iPad/iPhone on runtime touch handlers.

#10

Hi Adrian,

Yes, I was able to implement basic touch-panning and it works fast. I didn’t go so far as to work it in to multitouch, but you can see basic 1-touch dragging in the updated sample (attached).

Brent

#11

Hi Brett

Had to stop for a while but now back on with the port…  I’m still struggling with iPad performance.  I couldn’t really explain it so I’ve made a quick video to show you the behaviour.  I have lots of popup screens that behave just fine on pc/mac/android but not ipad.

I am loading them like this storyboard.showOverlay( “systemnotifications”, {time=200, isModal=true, effect=“fromLeft”} )

I’ve commented out the all the runtime events/touch handlers/timers and enterFrame on the main scene.  The only thing that is there is a small looping animation (the wind turbine) and a fps counter in the bottom left.  The number in brackets is the min FPS.  The project is set at 30fps.

As you can see from the video the flick/scroll behaviour is very erratic, sometimes it is very smooth and other times clunky and without any momentum.  Also note that when it is scrolling fine and you touch outside the bounds of the drawn area the scrolling stops dead and picks up where it should be when the touch ends.  I assume it is using delta time in an enterFrame?

Also note touching outside the bounds, or when the scrollView goes real clunky that the animation stutters (or pauses completely) and the frame rate drops dramatically. 

https://www.dropbox.com/s/996i6ly2xl6elhc/scrollview.mp4?dl=0

However, If I call it via gotoScene it runs just fine and as expected.  I have lots of different popups with scrollviews and they all suffer equally when shown as an overlay.  It is difficult to isolate to a test project because the data is hosted on my server.

Any idea what is causing the difference in behaviour? If it helps, I can have a full 70x70 grid with thousands of buidlings (each with its own touch handler) and show an overlay and scrolling is smooth and has proper momentum and the min FPS never drops below 20.

I really want them as overlays rather than scene transitions because it looks much more slick.

Thanks

Adrian

P.S.  I resolved my last issue by adding display.getCurrentStage():setFocus( self ) on phase = “moved” on the runtime handler if the move was more than 5 pixels.  I couldn’t put it in phase = “began” (as in your example) because each tile can have a building on it and that building has it’s own touch handler and that stopped the building’s touch handlers from firing.

#12

This is just a suggestion, but have you checked that you are not accidentally adding any listeners multiple times when you go to scene (or when you leave and come back). It could be that the same enterFrame listener is running multiple times per frame or something like that.

#13

Just FYI…

I solved it by doing a display.Capture on main DG, inserting that above, freezing all animations and then fading out the main DG.  Then the scrollViews in overlays behave properly.  Upon overlay termination, I kill the capture, restart the animations and fade back in the main DG.  It’s a hack and I don’t like it but at least it works and I can publish on iOS. 

The only thing I can think of is on iOS overlays are somehow allowing touch events to propagate to the scene below but the scene below can’t actually intercept the events (print statements never fired on the touch handlers on objects in the main scene) and this causes massive event bubbling which drags the performance down to a crawl.  This does not happen on Android and therefore the issue lies in the SDK somewhere.

#14

I have managed to isolate this behaviour by modifying the sample pinch zoom… It is when you drag/pinch/zoom a display group with lots of nested graphics.  This doesn’t happen on Android.  

How to I send you a sample so you guys can see it?

#15

Hi @adrianm,

Dropbox is a popular way to share files… just zip up the project and post it there.

Thanks,

Brent

#16

Hi Brett

A use case is here http://www.spheregamestudios.com/ipad_issues.zip. works just fine on android and sim but not ipad/iphone

Thanks

Adrian

#17

Hi Adrian,

This seems to be some issue in your code. It appears that you’ve based this project on Corona’s “PinchZoomGesture” sample, but you’ve added a lot of unnecessary complication to it, as far as I can tell. I just took that same sample base and added your giant “grass” grid into it, instead of the single stock “aquarium” image, and I named the overall display group for all the tiles “background” (although you could rename this as needed). This group (“background”) is then used as the touchable object, not the Runtime.

I then installed the app on my iPhone and it’s quite smooth when I pinch-zoom in and out. In contrast, I installed your sample on the same iPhone and it’s very slow and clunky. So, there’s some issue in your code, and it’s not a Corona issue.

Hope this helps,

Brent

#18

Hi Brent

Thanks for looking into it.  I’ve isolated the problem further and I do believe it to be a Corona issue.  If I insert the grass tiles directly into the background display group then you are right, the speed on device is fine.  But, if I insert the grass tile into a new display group and then insert that into the background display group then it is unusable on iPad/iPhone.  However, this massive performance degradation does not happen on Android devices.

Could you please make that minor change to your test code and you will see the issue.

Thanks

Adrian

#19

Hi Adrian,

I used display groups within a larger display group and the performance is just fine, so it’s still something in your code. I’ve attached the “main.lua” file that I used for testing on my iPhone5 (didn’t test on iPad but the results shouldn’t be vastly different… if anything, it should be faster depending on which generation of iPad you have).

Note that this demo only shows pinch-zoom, not x/y scrolling, but I see no reason why the performance would degregate for scrolling.

Brent

#20

Hi brett

I see your main.lua does indeed perform fine on pinch zoom on iPad 2. So therefore it must be down to the touch event but i cannot see why yours performs so differently to mine when they are so similar.  Can you see anything in my touch event that might cause the massive degradation compared to yours?  I need the touch event to pan as well as zoom as this is quite standard for games.

Can you get your sample to pan as well as zoom?

Thanks

Adrian