Swf embedding heap section issue

Help
#1

I see this issue mentioned here: Always getting 'Fatal error in gc' Too many heap sections
And here: Assets from external .swf files

But not sure if people want me bumping, does this have no workaround for html5? I’m just trying to embed 9 swfs totaling 7.4mb. I have a Haxe+Flash game that I’m trying to port, I don’t think the runtime bundle hack works because I need the assets embedded for typecheck to pass.

Also, there’s a workaround for a similar issue in hxcpp here, but don’t think it’s relevant: https://github.com/HaxeFoundation/hxcpp/issues/853

Edit: The base swfs total 7.4mb, doing openfl process on them shows, that they’ll total ~50mb once in that .zip format.

The verbose flag implies that it’s an issue with them being sequential

Running command: UPDATE
 - Running command: haxelib run swf process C:\msys64\tmp/temp_2965201 C:\msys64\tmp/temp_13991765 -verbose --targetDirectory=c:\swfBin\html5
 - Processing library: res/AnimationDebugger4.swf [SWF]
 - Creating directory: swfBin/html5
 - Creating directory: swfBin/html5/obj
 - Creating directory: swfBin/html5/obj/libraries
 - Processing library: res/SofiAnim.swf [SWF]
 - Processing library: res/ZaraAnim.swf [SWF]
Error: Could not process asset libraries (swf, swf, swf, swf, swf, swf, swf)

But I’m can run openfl process on each one individually, could this be theoretically bypassed so that I could just supply the zips?

Edit2: I’d also like Type.getClassName(Type.getClass(X)) to work on them, but right now it only seem to work if you also give the movieclips an instance name. https://imgur.com/a/L45voiz
mc.__timeline.__symbol.className seems like is always have the right data, but it’s private, never returned, and I don’t see where I could change it to public.

#2

Yes it is possible to use openfl process then to use AssetLibrary.loadFromFile at runtime or to use openfl.display.Loader (though that only allows seeing the main timeline)

It sounds like there might be an issue with memory running out in the SWF processing tool. I think it tries to process all SWFs in memory before writing them out at the end. Perhaps it would be possible to make the Lime tools call the processing tool once per file rather than once for all, or some quick fixes in the SWF library might help reduce memory pressure

#3

Thanks for the reply. I did end up getting it working, if you baby the obj directory and delete the .zip files that get corrupt, you can build everything because the old stuff will get cached.

I started to look at the swf lib, but it’s a real OOP nightmare, hundreds of mostly empty classes blow through the whole 32bit heap by fragmenting unpredictably. It’s very hard to wrap my head around. >.<

Also, for people in the future, this snippet works to get class names after setting private fields to public:

var str:String;
if (!Std.is(obj, MovieClip)) {
	str = "";
} else {
	var timeline:Dynamic = cast(obj, MovieClip).__timeline;
	str = timeline.__symbol.className;
}
1 Like
#4

A big help would be for the SWF exporter to either A.) run once per SWF file or B.) for the exporter to commit a processed SWF file to disk (and flush memory) before processing the next.

Here’s the file:

It’s rebuilt using lime rebuild swf or cd swf/scripts && haxe run.hxml

Here’s where Lime calls external tools to process asset libraries (in this case, to call the SWF tools):

lime/AssetHelper.hx at 1b809a4918780e01f73c9dfdb608ba83a3cfbde7 · haxelime/lime (github.com)

It calls it once per handler, so it will call the SWF tools once with the Lime project and ask for the SWF tools to return processed libraries. This could be changed to run once per library, though it could be nice for performance if we could figure it out on the SWF tool side