HyperPad App Performance degrades until crash to home screen
-
hyperPad (latest version) degrades in performance steadily, until about 30 minutes In, it crashes.
I remember @murtaza at one point saying with WiFi enabled, crash reports would automatically send to the @administrators, but I’m wondering if this is still the case. If it isn’t, I may start a crash report megathread if deemed necessary.
Model: iPad mini 2
Firmware: 11.2
HyperPad: 1.2 (latest) -
@thecheater887 Perhaps go a bit further, make this wider known and the title clearer, about the frequency of crashes. This is valuable information. Thank you.
-
@deeeds (should be) Fixed.
-
"hyperPad (latest version) degrades in performance steadily, until about 30 minutes In, it crashes. "
That sounds exactly like a memory leak coming from not fixing the issue at the core of cocos2D, a game loop dependency on the (flawed and irregular) CADisplayLink. Apple claims to have made CADisplayLink more reliable since iOS 11. It's only true if you're not reliant upon it, and fully understand why it fluctuates. Nobody does. And Apple isn't about to tell us why, because that will likely indicate what they're planning in terms of higher speed displays and adaptive frame rates.
btw, the older version of hyperPad also leaks memory, and eventually crashes, too, even on the latest Apple iPads. I've watched it in Xcode's profiler. But it did take a lot of time before it crashed, hours of use. Not 30 minutes. It would get unstable for me, often, well before it crashed, creating all sorts of weird issues.
One "fix" you can try is to pull down the notifications tray whilst you're running your game in play mode. And then exiting back to editing mode. This causes a brutal flush of the memory (on the older version) that brings some stability back.
-
If it is a memory leak, my iPad model boasts only 1GB if RAM, and I’m working on a rather sizable project, explaining the short time between crashes.
-
@thecheater887 It's disappointing to see this isn't fixed. It's a core and crucial issue with older versions of cocos2D, and easily fixable, with a side effect of massively increased stability and consistent performance.
-
@Deeeds the fix you suggested isn’t feasible. I’ve taken a look, and what you’re suggesting isn’t actually a memory leak...
I get that you think you know how to use tools, but when it’s built for the App Store, the profiler doesn’t show everything. Everything gets lumped together.
We haven’t noticed degradation to that scale to cause it crash after a certain time period. If you guys can email your projects, we can actually profile it properly.
Please give steps on how to reproduce.
-
@hamed I can try to record my actions prior to the degradation, but nothing stands out of the ordinary.
Something I can tell you, however, is aside from the slight frame drop that increases over time, if you Loop behaviors (say connect a behavior bundle to a wait, to a get label, to the first wait), the line that connects them (plug) will do something similar to 3D Z-Fighting. It swaps sides when you scroll the white background the behaviors sit on. This tells me the crash is imminent in the next 10 minutes. It seems to crash most often when undoing, redoing, or just after play mode scene initialization (the lag spike in immediate changes, moves, and where you count pull the de bug menu up). UPD: also, just before the app is about to crash, the grey curvy lines don’t render when attempting to connect separate behaviors.
-
@hamed I know it's not ACTUALLY a memory leak, but it does 'leak' memory.
I know the reason, too. The lock cocos2D takes on the thread that would normally release objects, due to the reliance on CADisplayLink falling a frame (or more) behind real time. This is the exact reason that creating an iOS level interruption permits an unlocking of this thread to release objects and release the "leak".
As to what you're saying is not feasible... what and why? You mean resorting to Mach time at the core loop level isn't feasible?
-
@hamed this locking, from the reliance on CADisplayLink falling behind, is also why hyperPad drains batteries. It's 100% CPU usage essentially looking/waiting for the next CADisplayLink, but which isn't enough for it to get back in front of itself. A loop just flogging and thrashing the system, needlessly.
