Did not help. Everything remains unchanged.
Did you run lime rebuild android after making the change (if you’re testing on Android)?
I use a simple build script:
lime rebuild lime android
lime test android
And I see in the log and by the result that all my changes.
For three weeks of experiments, I noticed that performance drops due to pixel operations, not Draw calls. One small picture stretched over the entire screen is enough to drop the FPS.
Can this answer help?
My experience is not enough to solve this problem.
I have already tried many open source games that use SDL2, and have just come across the first one that runs smoothly.
Hope this helps.
That’s an interesting find
We did change our default color mode to 32-bit instead of 16-bit some time ago:
I assume that MSAA is also off but you could check that as well
SDLWindow.cpp This is the first file with which I began to conduct experiments. All to no avail. It looks like a problem somewhere deeper in the SDL.
Suspiciously that changing the format does not change the final render.
test code:
package;
import openfl.display.Sprite;
import openfl.display.BitmapData;
import openfl.display.Bitmap;
import openfl.display.FPS;
import openfl.events.Event;
class Main extends Sprite {
private var bitmap : Bitmap;
private var bitmapData : BitmapData;
private var fps : FPS;
public function new () {
super ();
bitmapData = new BitmapData ( 1024, 1024, true, 0x00000000 );
generateBG ();
bitmap = new Bitmap ( bitmapData );
bitmap.width = stage.stageWidth;
bitmap.height = stage.stageHeight;
addChild ( bitmap );
fps = new FPS();
addChild ( fps );
}
public function generateBG () {
var sprite = new Sprite ();
var stepHeight = bitmapData.height / 6;
sprite.graphics.beginGradientFill (LINEAR, [0xFF0000,0x000000], [1,1], [0,255]);
sprite.graphics.drawRect( 0, 0, bitmapData.width, stepHeight );
sprite.graphics.beginGradientFill (LINEAR, [0xFF0000,0xFF0000], [0,1], [0,255]);
sprite.graphics.drawRect( 0, stepHeight, bitmapData.width, stepHeight );
sprite.graphics.beginGradientFill (LINEAR, [0x00FF00,0x000000], [1,1], [0,255]);
sprite.graphics.drawRect( 0, stepHeight*2, bitmapData.width, stepHeight );
sprite.graphics.beginGradientFill (LINEAR, [0x00FF00,0x00FF00], [0,1], [0,255]);
sprite.graphics.drawRect( 0, stepHeight*3, bitmapData.width, stepHeight );
sprite.graphics.beginGradientFill (LINEAR, [0x0000FF,0x000000], [1,1], [0,255]);
sprite.graphics.drawRect( 0, stepHeight*4, bitmapData.width, stepHeight );
sprite.graphics.beginGradientFill (LINEAR, [0x0000FF,0x0000FF], [0,1], [0,255]);
sprite.graphics.drawRect( 0, stepHeight*5, bitmapData.width, stepHeight );
bitmapData.draw ( sprite );
}
}
render:
SDL_GL_SetAttribute (SDL_GL_RED_SIZE, 8);
SDL_GL_SetAttribute (SDL_GL_GREEN_SIZE, 8);
SDL_GL_SetAttribute (SDL_GL_BLUE_SIZE, 8);
SDL_GL_SetAttribute (SDL_GL_ALPHA_SIZE, 8);
SDL_GL_SetAttribute (SDL_GL_RED_SIZE, 5);
SDL_GL_SetAttribute (SDL_GL_GREEN_SIZE, 6);
SDL_GL_SetAttribute (SDL_GL_BLUE_SIZE, 5);
SDL_GL_SetAttribute (SDL_GL_RED_SIZE, 3);
SDL_GL_SetAttribute (SDL_GL_GREEN_SIZE, 3);
SDL_GL_SetAttribute (SDL_GL_BLUE_SIZE, 2);
They are all the same.
Shouldn’t the final pictures be different, or am I misunderstanding something?
If Android uses EGL it looks like it tries to pick a matching config:
…but I don’t know whether the config it is choosing is “native” for the device or not?
It is transmitted quite reliable information:
But the pixel format does not change.
I have the exact same problem with performance loss. I’m using Stencyl game engine that uses OpenFL and when they updated OpenFL from version 3.6.1 to newer (6.2.2, 8.0.0, 8.7.0, etc.) versions I noticed a significant performance drop with almost nothing on the screen. There is already a thread on Stencyl forums with the same issue as this.
Basically, in the version 3.6.1, you could have more than 10 background / tile layers with multiple actors and tiles and still managing to get 60 FPS. In the newer versions, the FPS can drop below 30 FPS by just having the background layers without any actors or tiles on the screen.
As Vortelio said, it can be a simple game with almost no assets and the FPS will still drop below FPS, while the OpenFL Legacy can maintain at solid 60 FPS with no problem.
Tests with different combinations are visible in the link above.
Is this problem on Windows, macOS, Android, iOS or HTML5?
According to this instruction, I changed the function SDL_EGL_ChooseConfig and got 22 config instead of two. I went through them manually, some give a black screen, some reduce FPS even more. There is no config which increases FPS.
All the same, the gradient remains smooth regardless of the RGB bit. It is strange, I expected sharp gradations.
Only on Android. For some reason it works kinda better on older devices since the resolution is lower, even though the CPU’s and GPU’s on those devices are worse.
Do either of these changes help?
I did not notice any difference.
Good news:
After some fixes in the SDL (post on the forum, Sdl 2.0.10 prerelease), and now in dev lime is the latest version of the SDL, I rechecked all the devices again.
This applies only to low-performance devices.
Tested on a real project.
Information about opengles take here:
stage.window.context.type
stage.window.context.version
-
smartphone 720x1280 - RGBA8888 - opengles 3
It was FPS: 15 - 30, Cairo was sometimes activated.
It became FPS: 50 - 60, now always opengles 3. -
smartphone 480x800 - RGBA8888 - opengles 3
It was FPS: 20 - 40.
It became FPS: 60. -
Tablet 1280x800 - RGB565 - opengles 2
It was FPS: 15 - 25.
It became FPS: 15 - 25.
Nothing changed.
I do not have a device with RGB565 and opengles 3, I doubt that they are. In SDL, there are obvious problems with drawing in RGB565.
Maybe there is no problem, and the percentage of such devices is already small? Someone has probably already released games on the new OpenFl (not legacy), are there really no user complaints?
2 Likes
Depending on the age of your tablet, when OpenGL ES 2.0 came out (and drivers switched from the fixed to the programmable pipeline) there was a definite hit in performance when going with OpenGL 2.0 versus OpenGL 1.0
Do you mind sharing what device and Android version it’s running?
VERY great to hear that performance has picked up with the other devices!
I did not know about this nuance. It turns out the problem was not there?
<<< System >>>
Device Model: Asus MeMO Pad HD 7 (ME173X)
Device Type: Tablet
Manufacturer: asus
Model: ME173X
Installed RAM: 1 GB
<<< CPU >>>
SoC Model: MediaTek MT8125
Core Architecture: 4x ARM Cortex-A7 @ 1209 MHz
Instruction Set: 32-bit ARMv7
<<< Display >>>
Screen Resolution: 800 × 1280
Technology: IPS LCD
Screen Size: 94 mm × 151 mm
Screen Diagonal: 7.0 inches
Pixel Density: 216 dpi (tvdpi)
xdpi / ydpi: 213 / 213 dpi
GPU Vendor: Imagination Technologies
GPU Renderer: PowerVR SGX 544MP
Refresh Rate: 58 Hz
Default Orientation: Portrait
OpenGL ES Version: 2.0
GPU Version: OpenGL ES 2.0 build 1.9@2564405
OpenGL ES Extensions: GL_EXT_debug_marker
GL_OES_rgb8_rgba8
GL_OES_depth24
GL_OES_vertex_half_float
GL_OES_texture_float
GL_OES_texture_half_float
GL_OES_element_index_uint
GL_OES_mapbuffer
GL_OES_fragment_precision_high
GL_OES_compressed_ETC1_RGB8_texture
GL_OES_EGL_image
GL_OES_EGL_image_external
GL_OES_required_internalformat
GL_OES_depth_texture
GL_OES_get_program_binary
GL_OES_packed_depth_stencil
GL_OES_standard_derivatives
GL_OES_vertex_array_object
GL_OES_egl_sync
GL_OES_texture_npot
GL_EXT_multi_draw_arrays
GL_EXT_texture_format_BGRA8888
GL_EXT_discard_framebuffer
GL_EXT_shader_texture_lod
GL_IMG_shader_binary
GL_IMG_texture_compression_pvrtc
GL_IMG_texture_compression_pvrtc2
GL_IMG_texture_npot
GL_IMG_texture_format_BGRA8888
GL_IMG_read_format
GL_IMG_program_binary
GL_IMG_uniform_buffer_object
<<< Android >>>
Android Version: 4.2.2 (Jelly Bean)
API Level: 17
No OpenCL devices found.
No CUDA devices found.
No Vulkan devices found.
No PCI devices found.
I have the same issue.
WIth openfl 8.9.5 + starling 2.5.1 I have drop of fps during some time from 60 to 30 
Also this happens if I use losseless (uncompressed pngs) in fla with pure OpenFL.
Do I need to use dev lime to fix this issue?
Also I didn’t find downloadable binaries of lime.
I have this issue on Android in Chrome. Samsung Galaxy S6
UPD: I’ve rebuilt the project with dev lime and dev openfl. But the issue still remains
Please, help
Link to chrome profiler’s log:
http://188.166.108.195/Profile-20191209T165246.zip