Huge pause after first frame and before second

I’m having a problem on native targets where my game seems to pause after the first frame for about 10 seconds at a white screen before anything happens. I’ve traced some time stamps in my Main class constructor and an EnterFrame event. I get this:

End of constructor,0.618
Start of game update,0.618,0
End of game update,0.618,0
Start of game update,12.011,1
End of game update,12.014,1

This doesn’t happen in Flash. I get a 10+ second pause in Neko and around 5 seconds in Windows. Any ideas what might be causing this? I’m pretty sure it’s not my code directly as I only have the one enter frame listener and the traces are at the beginning and end of that. Could I be triggering something in OpenFL that may take some time at startup e.g. font generation or image loading? I haven’t put any audio in but have noticed this delay since adding some images and a ttf font. This only seems to affect the very first frame.

Any help appreciated.

To add to this, with the Android target, the game gets to the end of the first frame, waits a few seconds and then crashes with the message:

Fatal Signal 7 (SIGBUS), code1, fault addr 0xa547c172 in tid 27338 (SDLThread)

There are warnings earlier in execution that say:

libApplicationMain.so has text relocations. This is wasting memory and preventy security hardening, Please fix

AUDIO_OUTPUT_FLAG_FAST denied by client
pthread_create sched_setschedular call failed: Operation not permitted

Not sure if this has anything to do with it.

Have you tried updating to the latest versions? Could you see how a standard openfl test compares to with -Dlegacy or -Dhybrid added?

I’m using openfl 3.0.1 and lime 2.3.1.

Using the lime-hybrid define in the xml, the pause in Neko shifts to before the constructor finishes and lasts 2.5 seconds. With openfl-legacy set in the xml there is no pause at all.

Android target works fine with openfl-legacy but with lime hybrid it pauses for 5 seconds then crashes with this error:

04-09 22:46:51.145: E/HXCPP(3687): Called from ApplicationMain::main ApplicationMain.hx line 396
04-09 22:46:51.145: E/HXCPP(3687): Called from ApplicationMain::create ApplicationMain.hx line 329
04-09 22:46:51.145: E/HXCPP(3687): Called from lime.app.Application::exec lime/app/Application.hx line 158
04-09 22:46:51.145: E/HXCPP(3687): Called from lime._backend.native.NativeApplication::exec lime/_backend/native/NativeApplication.hx line 102
04-09 22:46:51.145: E/HXCPP(3687): Called from extern::cffi c:/haxetoolkit/haxe/lib/hxcpp/3,2,37/src/hx/Lib.cpp line 119
04-09 22:46:51.145: E/HXCPP(3687): Called from lime._backend.native.NativeApplication::handleWindowEvent lime/_backend/native/NativeApplication.hx line 59
04-09 22:46:51.145: E/HXCPP(3687): Called from lime.app.Application::onWindowResize lime/app/Application.hx line 455
04-09 22:46:51.145: E/HXCPP(3687): Called from openfl._legacy.display.HybridStage::onWindowResize openfl/_legacy/display/HybridStage.hx line 274
04-09 22:46:51.145: E/HXCPP(3687): Called from openfl._legacy.display.ManagedStage::pumpEvent openfl/_legacy/display/ManagedStage.hx line 80
04-09 22:46:51.145: E/HXCPP(3687): Called from extern::cffi c:/haxetoolkit/haxe/lib/hxcpp/3,2,37/src/hx/Lib.cpp line 126
04-09 22:46:51.145: E/HXCPP(3687): Called from openfl._legacy.display.Stage::__processStageEvent openfl/_legacy/display/Stage.hx line 551
04-09 22:46:51.145: E/HXCPP(3687): Called from openfl._legacy.display.ManagedStage::__doProcessStageEvent openfl/_legacy/display/ManagedStage.hx line 108
04-09 22:46:51.145: E/HXCPP(3687): Called from openfl._legacy.display.Stage::__pollTimers openfl/_legacy/display/Stage.hx line 1059
04-09 22:46:51.145: E/HXCPP(3687): Called from openfl._legacy.display.Stage::__checkRender openfl/_legacy/display/Stage.hx line 339
04-09 22:46:51.145: E/HXCPP(3687): Called from openfl._legacy.display.ManagedStage::__render openfl/_legacy/display/ManagedStage.hx line 121
04-09 22:46:51.145: E/HXCPP(3687): Called from openfl._legacy.display.Stage::__render openfl/_legacy/display/Stage.hx line 1085
04-09 22:46:51.145: E/HXCPP(3687): Called from extern::cffi c:/haxetoolkit/haxe/lib/hxcpp/3,2,37/src/hx/Lib.cpp line 119
04-09 22:46:51.145: E/Exception(3687): Bad ByteArray
04-09 22:46:51.160: V/SDL(3687): onPause()
04-09 22:46:51.161: V/SDL(3687): nativePause()
04-09 22:46:51.161: E/libEGL(3687): call to OpenGL ES API with no current context (logged once per thread)

Interesting about the delay, you said that Neko has a 5 second delay before the constructor, this is before your Main class is called?

This is on a different computer so it seems to run faster but the delays are still there. For comparison this is the Neko openfl-legacy version:

Start of constructor,1.89235271401868e-005
End of constructor,0.0286470127127614
Start of game update,0.029048255635683,0
End of game update,0.0292208125441816,0
Start of game update,0.0441553243107667,1
End of game update,0.0444654777132168,1

the lime-hybrid:

Start of constructor,0.212
End of constructor,0.957
Start of game update,0.958,0
End of game update,0.958,0
Start of game update,0.972,1
End of game update,0.972,1

and the default version:

Start of constructor,0.189
End of constructor,0.217
Start of game update,0.217,0
End of game update,0.217,0
Start of game update,4.565,1
End of game update,4.565,1

Oh, so the boot up is faster, but the first update is slower. What kinds of things are you doing in that first frame? Are you doing bitmap manipulation, or anything like that?

Nothing intensive. I’m setting up my stage with a few bitmaps loaded using the Assets class. I’m also creating a few text fields, all using the same font.

I tried removing the font and this made no difference. Have just been reading another thread about alpha blending and premultiplied alpha was mentioned as a difference between versions. Could the premultiplying code be taking a long time? I have about 15 images so far that range from small to full screen size 1334x750. Could this be the issue?

Hmm, possibly… this is Neko? It particularly would be slow at pixel operations. Perhaps we should do some CFFI for some of the real intensive operations within Lime Image, then leave the rest up to regular Haxe code