Fatal crash at startup in Chrome


I have just cleaned up my system to install HaxeDevelop and the newest Haxe + libraries, and now, when compiling to HTML5, Chrome launches the game and at a certain point (I think the parsing of a spritesheet… I suspect of copypixel procedure but I could be wrong) both the 2 screens go blank and I am forced to reset the PC. Sometimes one of them resurrects a few seconds later, but rarely.

With Firefox the game runs and starts correctly (just shows the warning “A web page is slowing down your browser, what do you want to do, wait or stop it?”, but the game starts immediately after). It looks like a sort of overflow… that Chrome can’t handle. What changed between the old Haxe/Lime/Openfl (I was using Haxe 3.2.1 + Lime 5.6.0 + Openfl 6.2.0) and the latest ones? The spritesheet initialization (always copypixel :expressionless: ) is the biggest suspect, imho.


Anything above 6.5.0 has broken the implementation of sprite’s “mouseEnabled” (https://github.com/openfl/openfl/issues/1777)

Maybe something else broke? Can you check what happens with 6.5.0?


It seems to hang when doing copyPixels: I think that the loops that extracts hundreds BitmapsDatas from different spritesheets contemporarily are flooding memory.
Now I am trying to create a simple scheduler to at least avoid multiple copyPixels calls on the same spritesheet, I wonder if it is possible to know when a copyPixel is complete to start the next one: @singmajesty is this possible?

Firefox crashes too, it is a BIG problem! I will try to downgrade Openfl to an older version.


Are you using OpenFL development versions, or the latest release?

Does this help?


No dev, latest ones.
I have downgraded to 5.8.2+6.5.0, but nothing changed.

Trying to restore the commented copyPixel code…

EDIT: nothing changed, still crash.
I have found something interesting: I have downgraded to the same versions of Lime and Openfl I was using before the HaxeDevelop/Haxelib upgrade, and the game keeps crashing… does this mean that the culprits are not Lime and Openfl but Haxe itself?


Maybe it is your browser? Perhaps your game is using too much RAM for your system at the moment?


Both Chrome and Firefox? And why this morning all games worked as always and after HD and Haxelib upgrade they don’t work anymore? It is difficult for me to believe that the problem is related to browser only.


Confusing why it would be the same if you use either a newer or older OpenFL version, unless something else was updated, or (perhaps?) somehow you have extra files being copied in your assets directory, so you are preloading more files than you intend?


I am compiling the exact same applications as before I updated FlashDevelop to HaxeDevelop and Haxe 3.2.1 to 3.4.4.

Oh, I forgot to specify that our games use different assets with the same names.
I have just found that cleaning the browser cache when I switch project the application starts: till yesterday it was not “always” necessary, at worst a game was showing the assets of another game, but never caused a browser/video crash.
Maybe something about cache usage has changed a little: to avoid this kind of problems I could adopt one of these solutions:
1 - force cache buster for all files
2 - use different filenames for all games by adding a unique code to filenames

To use solution 2… is it possible to rename filenames at compile time by adding a suffix (filename.png -> filename123.png)?


Currently Lime releases should have a cache buster string attached at the end, when you use the standard asset system. You should be able to use lime.utils.Assets.cache.version to get the string we use, if you need it. You may also need -clean builds, periodically, if the way your assets XML is configured, it copies (and preloads) more files than are needed

You can do a rename in an <assets /> tag, but only on an individual file basis, or to a different folder, I don’t think its possible to wildcard rename file names