search

Gamua / Starling-Framework

The Cross Platform Game Engine
http://www.starling-framework.org
Other
2.82k stars 820 forks source link

Starling pause #772

Open Pandan opened 8 years ago

Pandan commented 8 years ago

Hi!

I am having a problem with performance in an ANE on iOS when running Starling(and Feathers). I partially solved it setting Starling.current.nativeStage.frameRate = 1 when the ANE is active. This makes the ANE perform well, but the navigation(button in feathers) that closes the the ANE is responding a bit slow. I am guessing this is connected to Starling rendering in a low framerate, it responds much faster when I leave the frameRate at 60.

In my case I don't need to update any visual stuff but I still want receive touches fast. Do you have any suggestion on how to go about to solve this.

Here is a link to a thread in the forum that discuss this problem. It's quite old and maybe Starling has been updated with some new feature that solves my problem. http://forum.starling-framework.org/topic/how-to-pause-starling

kheftel-old commented 8 years ago

Sounds like your ane is exposing some sort of native interface. If so, can you put the close button in the native interface? We've put storyboards and such into our ane on iOS and it works pretty well.

Thanks,

Kawika Heftel Heftel Studios 801-358-9830 http://www.heftelstudios.com

Pandan commented 8 years ago

The ANE is using the mapview on ios. But the navigation is in air and the responsiveness when picking up the touch seems to be slow when running Starling with a frameRate of one. Not knowing how starling is handling touches, but it seems to be connected. Cause it feels slow even when I am not using the ANE, instead just testing with a button and switching the frameRate between 1 and 60. It would be nice to have a feature that somehow halts the rendering but still picks up the touches.

PrimaryFeather commented 8 years ago

Hm ... you're right, a low framerate will also slow down event processing in Starling. That's currently done at the same time interval.

There could be a very easy workaround, though. Starling exposes the "TouchProcessor" with a property of the same name. Try to call its "advanceTime" method manually, e.g. 60 times per second, with a timer or a setInterval call. That might solve your problem.

Please try it out and let me know if that helps!

Pandan commented 8 years ago

@PrimaryFeather thanks for the suggestion. It worked out perfectly. I am using setInterval and calling "advanceTime" passing a 0 The response of the the touch is performing as when running Starling at 60 fps and the performance of the ANE is great!

jamikado commented 8 years ago

You might actually want to pass the actual time passed instead of 0, otherwise the touch processor will not compute multi-tap touch tap counts accurately if you were going to ever use that property during this period.

Pandan commented 8 years ago

Okej! And passing the actual time passed, could I just use getTimer()?

jamikado commented 8 years ago

Sure, that is what Starling uses when computing 'since the last time you called it', just make sure you convert it to seconds and not milliseconds.

Pandan commented 8 years ago

Great! Thanks for all the help, I really appreciate it.

kheftel-old commented 8 years ago

sweet, glad you figured it out :)

PrimaryFeather commented 8 years ago

Perfect, I'm glad to hear that this helps! =)

I'll try to make this easier in the future, thus I'm keeping this issue open as a "Feature". In the meantime, anyone else running into this issue can use the description above to get it working.

jamikado commented 8 years ago

I was also going to add, which it sounds like you are implying, since you are working on Starling 2.0, whether this might be part of a revamp of your Starling.stop() function. Maybe I got this wrong, but weren't you planning on changing the default for this in 2.0 from Starling.stop(false) to stop(true) by default (since almost everyone wants both rendering and advanceTime/eventing stopped). So maybe this variation on possibly wanting rendering stopped but not touch processing might imply a more configurable stop/start system for Starling 2.0 (with the defaults being ALL...)

PrimaryFeather commented 8 years ago

Good point, Jeff, thanks for bringing this up!

My plan is to first finish the revamped rendering system, and publish the GitHub branch when that's done (because I want a lot of feedback on those changes). After that, I'll tackle some other usability issues — like this one. :smile:

22Round commented 8 years ago

this would be great solution, waiting :)