[android] terrible performances, again

Can we, once for all, understand why performances are so unstable on android?
I have my new game - it is a minesweeper clone built in haxeflixel, so nothing complex/heavy - running nicely at almost always 60fps on my old huawei p9 lite. It is stuck at 30fps on newer huawei p20 lite.
I also tried on my old 7" tablet ASUS MeMO Pad ME173X (the same used here Old performance does not return?) and it runs at 8fps with the starting board (no updating, no new drawing).
On this latter device, bunnymark is running at 40fps with hiccups bringing fps down to 20 only with the app running (I am not adding any bunny).
Also, on this device, I found an old app I was developing for fun (an arkanoid clone, so with actual moving sprites) with and old version of haxeflixel, based on openfl 3.6.1 and lime 2.9.1 and it is running smoothly.
I know that the rendering pipeline has changed in the meantime, but why it seems to have worsened performances so dramatically??
Is there a way to choose the old rendering method?

1 Like

ASUS MeMO Pad ME173C uses a 16-bit screen. I tested a lot of games on SDL2, and they all work poorly. If you draw a small picture (for example 100x100), the FPS will be normal, but if you draw on the whole screen the FPS will drop critically. Pixel operations become very slow on such screens. For other cases, you should not use openfl.display.Graphics methods in real time. Especially bad was the changing TextField, which was constantly rendered even hidden (I don’t know how it is now). Even the FPS counter had to be converted to bitmaps. But now the text can be rotated at any angle, and not just a multiple of 90 degrees as before.

I think you can use <window color-depth="16" /> we used to default to 16 but currently use 32

Along with this setting. Can we use compressed pngs to improve performance like Starling FW (Adobe Air)?


still 8 fps on my game with <window color-depth="16" />
nothing changed…

We also removed an optimization to reduce the frequency of touch data events which affected some older devices

Can you specify the commit? is it openfl or lime?

In android vitlas, in the report “Slow rendering” such data:


This is a real disaster.

On my devices, I get smooth work, except for a few. Are there really so many of them in the play market. Or am I doing something wrong?

I watched the starling demo and the benchmark works very well on the ASUS MeMO Pad ME173X. Maybe some difference in the initialization of the graphics allows him to do this.

@Vortelio did you build the demo yourself? Using air or openfl?
@singmajesty does this mean something to you?

I used:
haxe: 4.1.1
hxcpp: 4.1.1
lime: 7.7.0
openfl: 8.9.6
starling: 2.5.1

openfl create starling:demo

Add to project.xml:

<window fps="60"/>
<android target-sdk-version="28" minimum-sdk-version="16"/>
<architecture name="armv7" />
<architecture exclude="arm64"/>

lime test android

This result:


Need to tap on “DriverInfo” to see FPS

Solution found.

We need to rewrite standard shaders, transfer everything that is possible from pixel operations to vertex ones.

According to this post:

“Measured performance on LG Nexus 4 vs. Samsung Galaxy S3 shows that Nexus 4 runs it more than 10 times faster.”

I modified DisplayObjectShader.hx and got superior performance in Tilemap and Bitmap, both on openfl_legacy.

I’m not very good at shaders. This is just an example that performance has fallen because of this. I would like to get the right shader from a professional for production.

7 Likes

Unfortunately I tried to build my game on Asus ME173X with your patch and I had no noticeable improvement

Testing for Asus ME173X

2000 bunnies, NO FIX

2000 bunnies, USE FIX

openfl create openfl-samples:BunnyMark

activate tilemap: add to project.xml <define name="use_tilemap" />

lime test android

I changed the shader that affects the tilemap and bitmap, I did not change the rest of the shaders. This is an example of a performance improvement.

Now I saw that in lime-samples there is a BunnyMark demo. This demo also uses a simple shader, and works great without modifications on the Asus ME173X. The patch is not needed for him, he does not need OpenFL. I propose to start checking with him.

haxelib install lime-samples
openfl create lime:BunnyMark
lime test android

1 Like

ok, I can confirm your test on openfl bunnymark demo with DisplayObjectShader patch and use_tilemap flag.
Are you saying that there is a particular shader that take care of default rendering (what is, drawQuads?) that we can tweak?

This is my first pull request in my life. I hope I did everything right.

To get full performance in BunnyMark, comment out the following lines:

//graphics.beginFill (0xFFFFFF);
//graphics.drawRect (0, 0, stage.stageWidth, stage.stageHeight);

Support: Tilemap, Bitmap, drawTriangles, drawQuads

BunnyMark

Snapdragon 625 1920x1080
before 60fps ~9500 bunnies
after 60fps ~23000 bunnies

Asus ME173X 1280x800
before ~15fps 2000 bunnies
after ~60fps 2000 bunnies

Is this going to fix performances also without use_tilemap flag?
Do you have benchmarks of your apps?

The test results above are when using drawQuads.

In my application, I got full performance on the Asus ME173X.

I am crying.
Cannot test right now but I am trying a build asap.

@Vortelio I cloned your openfl fork, branch patch-1, and unfortunately it is not working (tried my game and openfl bunnyMark)
I placed some traces in the render function in Context3DGraphics.hx after lines 602 and 725 and it is never called.
I was full of hopes and dreams :frowning:
Is there anything else I can try?