Freezes on HTML5


I have problem in my games, there is a freeze around every 15 seconds with absolutely no reason for it.
It completely ruins gameplay for some player with older computers.
I guess, it’s GC or something.
Here is the video of the problem:

My haxelib list:

hxcpp: [4.0.52]
lime: [7.6.3]
openfl: [8.9.5]

Any help with that?

You could try to profile it on chrome.
If it is the GC maybe you are creating objects every frame and piling up garbage too quickly?
If so, check the Lime’s ObjectPool class

Freezes clearly can be seen in profiler.
This is just main menu of the game, and I do nothing except rotating this one banner.

Also, I think the same problem exists on Android, but less noticeable.
Flash version works fine as usual.

Ok, this is happening with the latest version of OpenFL/Lime and as I started receiving complaints from Andorid devices, also on Android.

Here is old version profiler snapshot, and no freezes.

Unfortunately, I’m not sure what was the older OpenFL/Lime versions.

If you compare both screenshots, the “Nodes” count is clearly a hint to the memory leak.
So it looks like something keeps creating nodes each frame, and they get garbage collected after some time ?
On a side note, I ran the Spector plugin to check the draw calls, and your main menu is clearly missing some clipping because you draw all menu items, even when they are outside of the screen ! Some logical clipping could make scrolling in this menu much smoother :wink:

Hey @ tour1st,
Thanks for optimizations tip, good idea, I will try it.
My thinking was that ~40 buttons whether with clipping or not should not make much difference. :slight_smile:

Well, it seems to actually cost 2 draw calls per menu item : 1 for the image and 1 for the text below.
So rendering this menu takes at least 80 draw calls, which is already big for some old smartphones :slight_smile:

Side note 2 : nothing seems to be batched, which makes performance even worse in-game because each card is drawn independentely. Using a texture atlas with all figures/numbers would help a lot in this case :wink:

Thanks, any good example of batched drawing/atlas?

The way to go is using Tilemaps.

  • Create a texture atlas of all the images you want to pack together (there are some tools around, but I can’t remember any of them…)
  • Load this big bitmap and createo a Tileset object with it
  • Then create a Tilemap object with this Tileset, with the dimensions of the game screen (for example)
  • Create one Tile object per image to display, and add it to the tilemap
  • Add the tilemap object to your stage (since it’s a display object) and voila ! All tiles attached to the tilemap will be rendered in the same draw call, so 1 tilemap = 1 draw call :slight_smile:
1 Like

Reverting to OpenFL 8,9,1 and Lime 7,5,0 fix the problem.

I faced the same problem in my game. I can’t find what exactly causes this problem, but the frame rate has noticeably decreased and sometimes freezing, especially when using a bit of vector graphics. Had to return to 8.9.1 and all problems has gone. Not finding such problems on the forum, I decided that this applies only to my game (openfl shares context with away3d, etc.)

Any clues what code is allocating or what object type?

No idea. :slightly_smiling_face:
Where should we look for the problem?

Does this occur in any OpenFL samples?

One thing we want to figure out is if OpenFL internally is allocating new objects repeatedly that must be garbage collected – I don’t know off-hand the easiest way to figure this out using HTML5 debugging tools but a reproduction case (especially a simple one) is a good place to start

After some tests, I think problem is with the TextField.
If I remove all the text from the game completely, there are no freezes.
Using filters (GlowFilter in my case) with text makes these Nodes drops on freeze, like in my first screenshot.

Without filter, there is no problem with Nodes, but JS Heap drops and still freeze: