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.
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
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.
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.
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.