Rendering Performance on iOS and Android

Monkey Forums/Monkey Programming/Rendering Performance on iOS and Android

therevills(Posted 2011) [#1]
I think that the rendering performance is a tad slow on both iOS and Android with the generated code from Monkey.

For example in Pirate Solitaire on one level I am displaying a background image, 5 GUI sprites, 3 DrawTexts (Level, round and score) and about 40 cards... on my iPod I am getting around 25-28FPS.

On another level I am displaying 24 and get 40+FPS.

Also with the latest changes to the Android code (the buffer change) I have lost around 10FPS...

Any way to improve this?


MikeHart(Posted 2011) [#2]
Are you using single images or spritesheet? Do create/load images on the fly or before in the OnCreate event?


therevills(Posted 2011) [#3]
The GUI sprites are single images, the cards are on a spritesheet.

Images are created in the OnCreate event.


MikeHart(Posted 2011) [#4]
That sounds indeED weird. I will do some tests too.


Hima(Posted 2011) [#5]
Hmm I made a shoot'ing game with many bullets but I think the number of bullets on the screen is many more than that (100?) and it doesn't lag at all on iOS and Android. But this was since V32 or something, I haven't tried building V40 on mobile devices yet. Will do some tests and get back to you later.


therevills(Posted 2011) [#6]
Well both your devices outspec ours :P

We have a iPod 2nd Gen with a 620MHz CPU, yours is the 4th Gen with a 1GHz (running at 800MHz)

And a LG Optimus One P500 with a 600MHz CPU, your Galaxy S has a 1GHz CPU...


marksibly(Posted 2011) [#7]
Hi,

It's impossible to say why you're app's slow without being able to see what it's doing - can you post a demo of some kind?

> Also with the latest changes to the Android code (the buffer change) I have lost around 10FPS...

Bummer, but that's the 'right' way to do it so it stays.


Xaron(Posted 2011) [#8]
I have around 25-30 fps on my Android HTC Desire HD for my turn-based strategy game where the fps really don't matter. I don't do many stuff inside, just painting the map (one single image) and several units (images as well) on it. I think that's quite normal, you can't expect anything beyond 50 fps I guess.


therevills(Posted 2011) [#9]
Heres a very basic demo:



It creates 82 objects in 4 lists (Ships, Asteroids, Aliens and Cards), on my LG Optimus One I get 26 FPS.

Tap the screen to create more objects...

82 objects = 26FPS

102 objects = 22FPS

150 objects = 15FPS

210 objects = 11FPS

Code and Media here: http://www.therevillsgames.com/monkey/renderTest/RenderSpeedTest.zip

Flash:
http://www.therevillsgames.com/monkey/renderTest/flash/

HTML5:
http://www.therevillsgames.com/monkey/renderTest/html5/


Samah(Posted 2011) [#10]
Nexus One:
82 objects = 42 FPS
102 objects = 39 FPS
150 objects = 32 FPS
210 objects = 27 FPS

Motorola Xoom:
Frame rates fluctuate a lot.
82 objects = 50-60 FPS
102 objects = 40-55 FPS
150 objects = 30 FPS
210 objects = 30 FPS


marksibly(Posted 2011) [#11]
Hi,

I'll have a good look later...but first impressions are that there is a LOT going on there so I wouldn't expect stellar performance.

For starters, there is a lot of overdraw and this is a real killer for GLES hardware, which is very fill rate sensitive. Also, the use of alpha disables hardware optimizations that help eliminate this fillrate overhead, and also require an extra backbuffer read per pixel.

Not saying there aren't tweaks I can't make (in particular, I'm not thrilled about the use of glMatrix to do tforms - doing it manually would probably be faster) but the hardware has it limits.

Also, doesn't your phone use a crazy amount of CPU when idle? Or is that just when touch is used? Either way, it wipes out about 30% of performance from the CPU which is gonna hurt.

Anyway, will have a better look at work...


DGuy(Posted 2011) [#12]
My Results:
Objs | 82 | 102 | 150 | 210
-----+----+-----+-----+-----
GLFW | 59 |  59 |  59 |  59
iPad | 59 |  59 |  54 |  45
iPod | 59 |  59 |  53 |  45
Nook | 30 |  28 |  26 |  23
See sig for devices.


therevills(Posted 2011) [#13]
there is a lot of overdraw


Overdraw? Whats overdraw?

Or is that just when touch is used?


Only when you touch the screen - these FPS were taken without touching the screen.

I havent tested this on iOS, with Pirates I get around 30FPS on the device (60FPS in the simulator...)


Hima(Posted 2011) [#14]
@therevills
Overdraw? Whats overdraw?

Sprites drawn on top of another sprite. Devices prior to iPad 2 are strictly fillrate limited, so you should keep overdraw to be as few as possible.


therevills(Posted 2011) [#15]
lol... well that could be one reason Pirate Solitare is slow - Ive got cards on top of cards :/

Also arnt you always going to get that if you display a background image!?!?


xzess(Posted 2011) [#16]
Thanks Hima I will check that in my game also


therevills(Posted 2011) [#17]
Some testing results I have just been doing:

With a background:
------------------
No Alpha, 52 cards all overlapping     = 40    FPS
Alpha,    52 cards all overlapping     = 39-40 FPS
No Alpha, 52 cards none overlapping    = 41    FPS
Alpha,    52 cards none overlapping    = 39-40 FPS

No background just CLS:
-----------------------
No Alpha, 52 cards all overlapping     = 42-44 FPS
Alpha,    52 cards all overlapping     = 39-44 FPS
No Alpha, 52 cards none overlapping    = 43-45 FPS
Alpha,    52 cards none overlapping    = 41-45 FPS



So going on these, the overlapping (Sprites drawn on top of another sprite) didnt really hurt the framerate, nor the alpha - main performance increase was when we did not display a background image...


therevills(Posted 2011) [#18]
I've just been playing with an Android framework called Libgdx:

http://code.google.com/p/libgdx/

And created a very similar "game", which only diplays the ships with colour tinting, alpha and rendering on a background. I also changed the Monkey version to do the same.

This table shows my results (the left column is the number of objects):

    | Libgdx  | Monkey
----+---------+------
100 | 55FPS   | 22FPS
200 | 40FPS   | 12FPS
300 | 25FPS   | 8FPS
400 | 20FPS   | 5FPS


Here is the code for the Libgdx version:



And the apk if you would like to test:
http://www.therevillsgames.com/monkey/renderTest/libgdx/RenderTest-android.apk

The project(s) files:
http://www.therevillsgames.com/monkey/renderTest/libgdx/renderTestLibgdx.zip


DGuy(Posted 2011) [#19]
My android numbers (Using the LibGDX *.apk from previous post and Monkey implementation found below):
 Objs | Monkey | Libgdx
------+--------+--------
  100 |  37-38 |    38 
  200 |  30-31 | 33-34 
  300 |  25-26 | 29-30
  400 |  20-21 |    26

Monkey Implementation:
Import mojo.app
Import mojo.input
Import mojo.graphics

Class Sprite
Private
	Field _image:Image
	Field _xpos#, _ypos#, _angle#
	Field _r#, _g#, _b#, _a#
	Field _speed#
	Field _dx#, _dy#
	
	Method _Move:Void()
		Local x:= _xpos + _dx
		Local y:= _ypos + _dy
		If x < 0 Then x = DeviceWidth
		If x > DeviceWidth Then x = 0
		If y < 0 Then y = DeviceHeight
		If y > DeviceHeight Then y = 0
		_xpos = x
		_ypos = y
	End
	
Public
	Method New( image:Image )
		_image = image
		_r = 255.0 * Rnd
		_g = 255.0 * Rnd
		_b = 255.0 * Rnd
		_a = (255.0 * Rnd) + 0.5
		_speed = (4.0 * Rnd) + 1.0
	End
	
	Method SetPosition:Void( xpos#, ypos# )
		_xpos = xpos
		_ypos = ypos
	End
	
	Method SetRotation:Void( angle# )
		_angle = angle
	End

	Method Update:Void()
		_dx = (-Sin(_angle) * _speed)
		_dy = ( Cos(_angle) * _speed)
		_Move
	End

	Method Render:Void()
		SetAlpha _a
		SetColor _r, _g, _b
		DrawImage _image, _xpos, _ypos, _angle, 1, 1
	End
End

Class RenderTest Extends App
Private
	Field _shipList:List<Sprite>

	Field _background:Image, _ship:Image
	Field _frameRate, _frameCount, _frameCountStartTime

	Method _ShowFPS:Void()
		_frameCount+=1
		If _frameCount >= 30
			_frameRate = Int(1000.0 / (Float(Millisecs - _frameCountStartTime)/30.0))
			_frameCount = 0
			_frameCountStartTime = Millisecs
		End
		SetAlpha 1.0
		SetColor 255,255,255
		DrawText _frameRate, 0, DeviceHeight-12
	End

Public	
	Method OnCreate()
		_ship = LoadImage( "Ship1.png", 1, Image.MidHandle )
		_background = LoadImage( "galaxy2.png" )

		_shipList = New List<Sprite>
		For Local i:= 0 Until 400
			Local ship:= New Sprite( _ship )
			Local x:= Rnd( DeviceWidth )
			Local y:= Rnd( DeviceHeight )
			ship.SetPosition( x, y )
			ship.SetRotation( 360.0 * Rnd )
			_shipList.AddLast( ship )
		End
		
		SetUpdateRate 60
	End

	Method OnUpdate()
#If TARGET="android"
		If KeyHit( KEY_ESCAPE ) Then Error ""
#End		
		For Local ship:= EachIn _shipList
			ship.Update
		End
	End

	Method OnRender()
		Cls '<--- Actually improves fps
		DrawImage _background, 0, 0
		For Local ship:= EachIn _shipList
			ship.Render
		End
		_ShowFPS
	End
End

Function Main()
	New RenderTest
End



Loofadawg(Posted 2011) [#20]
Not always practical, but using JPG instead of PNG whenever possible can make a quite a difference depending on the situation/number of images. Also, if the images, need to be "resized" (or any other on-the-fly transformations for that matter) for before drawing then FPS is going to take a hit. Have not tested any of this on the latest versions of Monkey, but this has been my experience.

Yeah, probably obvious and once again not always a solution.

Far too lazy to post a demo.


Canardian(Posted 2011) [#21]
Samsung Galaxy S2 with Android 2.3.3 using original code: http://www.monkeycoder.co.nz/Community/post.php?topic=869&post=7218
82 - 198 objects = 60 FPS
202 objects = 58 FPS
302 objects = 39 FPS
390 objects = 29 FPS and crash after 30 seconds


skid(Posted 2011) [#22]
As has been pointed out, the original code is missing a Cls something that could perhaps be classed an error in mojo given it's ramifications in many EGL environments.


therevills(Posted 2011) [#23]
@Skid - what ramifications?

When testing I came across a strange issue when not using CLS and not displaying a background image - it displayed the view 3 times across the screen (split in 3rds).

Ill have to try to see the speed difference with CLS and drawing a background...


skid(Posted 2011) [#24]
This is from some apple docs I imagine android EGL stacks are similar:


Erase the Renderbuffers

At the start of every frame, erase all renderbuffers whose contents from a previous frames are not needed to draw the next frame. Call the glClear function, passing in a bit mask with all of the buffers to clear, as shown in Listing 4-2.

Listing 4-2 Erasing the renderbuffers

glBindFramebuffer(GL_FRAMEBUFFER, framebuffer);
glClear(GL_DEPTH_BUFFER_BIT | GL_COLOR_BUFFER_BIT);

Not only is using glClear more efficient than erasing the buffers manually, but using glClear hints to OpenGL ES that the existing contents can be discarded. On some graphics hardware, this avoids costly memory operations to load the previous contents into memory.



Summary: even if you intend to draw a fullscreen background you should call Cls at the beginning of your OnRender handler.


therevills(Posted 2011) [#25]
this avoids costly memory operations to load the previous contents into memory


I've been having some issues with PS on iOS (getting Program received signal: “0” crash), Mark has sent me some details to help... but I wonder if this will help too.

Thanks Skid!

[edit]
Just looking in mojo's ios code for Cls, it only does the GL_COLOR_BUFFER_BIT, does it need to do the GL_DEPTH_BUFFER_BIT too?
[/edit]


therevills(Posted 2011) [#26]
Just tested the Cls command on the Android version when displaying a background as well. On my phone it wasnt faster, I would say about half to one frame per second slower... (FPS counter shows 21-22)


Samah(Posted 2011) [#27]
Just looking in mojo's ios code for Cls, it only does the GL_COLOR_BUFFER_BIT, does it need to do the GL_DEPTH_BUFFER_BIT too?

Only if you enable depth testing, which is silly for 2D. I can't remember whether it's on by default but you can enable/disable with:
glEnable(GL_DEPTH_TEST);
glDisable(GL_DEPTH_TEST);


Edit:
http://www.opengl.org/wiki/Depth_Buffer

This is done by calling "glEnable(GL_DEPTH_TEST);". By default, depth testing is disabled when you create the GL context.



therevills(Posted 2011) [#28]
Using v41 I now get 25FPS in the same test as in post #18, so an increase of 3FPS :)

Still along way off Libgdx's 55FPS ;)


slenkar(Posted 2011) [#29]
check if anti-aliasing is turned on


DGuy(Posted 2011) [#30]
With v41, I'm seeing:

-> *LOSS* of 3-9 FPS using speedtest from post #19

-> *LOSS* of 2-3 FPS in my current app

Probably because some OGL hardware handles float operations faster than integer operations and visa-versa.

I'll be sticking with the pre-v41 "float" version of 'mojo.android.java' for now as it's faster on the primary android device I'm targeting (i.e. NookColor).


AdamRedwoods(Posted 2011) [#31]
Hi.

I looked at libgdx (SpriteBatch) and monkey mojo (surfaces), and it seems both are doing sprites the same way. The biggest difference is that libgdx will use OpenGL 2.0 shaders, if available. That may cause a speed increase.


But I hear that glDrawTexfOES is the fastest method for Android GL11 (slide 24 onwards):
http://www.scribd.com/doc/16917369/Writing-Real-Time-Games-for-Android

Other resources for Android speed tests:
http://code.google.com/p/apps-for-android/source/browse/trunk/SpriteMethodTest/README.TXT


marksibly(Posted 2011) [#32]
Hi,

> With v41, I'm seeing: -> *LOSS* of 3-9 FPS using speedtest from post #19

Hmm, that's a bit weird, it's supposed to be a win on all versions of Android up pre-honeycomb (3).

The issue is apparently due to some lazy coding in the implementation of android's floating point vertex buffers. Int buffers don't have this problem (again apparently) so the 'fix' is to convert floats->ints (bitwise), and use int buffers.

It's a minor win on my Galaxy S, but I can see how it'd be a loss on devices with 'fixed' float buffers, as the float->int conversion is a call per vertex component. Perhaps some pre-honeycomb devices have this fix in already?

My instinct here is to revert to float buffers, as int buffers aren't THAT much of a win, and float buffers will likely perform better on fixed/newer hardware.

The latest version of Monkey also includes an optimization for drawing 'non-alpha' images. Previously, ALL images were effectively being blended to the back buffer. Now, mojo checks image format/alpha and turns off blending when possible. Seems to work pretty well with large-ish images, not all that much difference with lots of small ones.

I also can't get any results from Cls-ing. I was thinking perhaps depth buffer may have to be turned on for it to work (ie: to make use of hierarchical z-buffers?), but that didn't seem to help either.


therevills(Posted 2011) [#33]
@DGuy - when you say pre-v41 what version did you test with?

V38 had the buffers as:
	gxtkGraphics(){
		vertices=FloatBuffer.allocate(MAX_VERTICES*2);
		texcoords=FloatBuffer.allocate(MAX_VERTICES*2);
		colors=IntBuffer.allocate(MAX_VERTICES);
	}


v39c had the buffers as
	gxtkGraphics(){
		ByteBuffer buf;
		
		buf=ByteBuffer.allocateDirect(MAX_VERTICES*2*4);
		buf.order(ByteOrder.nativeOrder());
		vertices=buf.asFloatBuffer();
		
		buf=ByteBuffer.allocateDirect(MAX_VERTICES*2*4);
		buf.order(ByteOrder.nativeOrder());
		texcoords=buf.asFloatBuffer();
		
		buf=ByteBuffer.allocateDirect(MAX_VERTICES*4);
		buf.order(ByteOrder.nativeOrder());
		colors=buf.asIntBuffer();
	}


^ this code is meant to be the "right" way of doing it (this is what I was talking about in the other thread: http://www.monkeycoder.co.nz/Community/posts.php?topic=941 )

When moving from v38 to v39, I lost about 10FPS, with v41 (int buffers) I had an increase of 3FPS. So from moving between v38 and v41 I lost around 7FPS. But in v38 I couldnt use the SDCard stuff and other features...


DGuy(Posted 2011) [#34]
(Remember I provided the same exact fix before I realized Mark has already done so .. ;) )

Was using v39c prior to v41 (skipped v40)


therevills(Posted 2011) [#35]
Okay, can you post your results using v38, v39c, v40 and v41 please? (original versions, no "fixes")


(Remember I provided the same exact fix before I realized Mark has already done so .. ;) )


lol - I forget who post stuff these days - must be getting old...


DGuy(Posted 2011) [#36]
I saw no performance change between v38 and v39c, and a (I think significant) performance drop with v41 ...


therevills(Posted 2011) [#37]
Well these are my results using the rendertest (post #18) with 100 objects:

    | v38 | v39c | v40 | v41
----+-----+------+-----+-----
FPS | 29  | 21   | 21  | 24



DGuy(Posted 2011) [#38]
Anyone interested in a slightly faster* (+0.5-1 fps) implementation of Android Mojo, look here:

<snip>

[Edit]
Moot as of Monkey v42 ...
[/Edit]


marksibly(Posted 2011) [#39]
Hi,

More improvements coming, but I'm moving this to programming for now...


therevills(Posted 2011) [#40]
Tested with a background with alpha and a background without - same FPS in v42:

    | v38 | v39c | v40 | v41 | v42
----+-----+------+-----+-----+-----
FPS | 29  | 21   | 21  | 24  | 22


So lost 2 FPS this time...


matt(Posted 2011) [#41]
Which device/phone is this on?

Any chance of posting the same results for different devices/phones?


therevills(Posted 2011) [#42]
This in on my LG Optimus One P500, using the same phone when using libgdx code I get 55FPS.


Rixarn(Posted 2011) [#43]
That's a huge difference therevills... what could be the bottleneck? I've read somewhere that SetColor for images is very slow in monkey

Btw, DGuy's number's seem very close to the ones got by the other lib... what is he doing in his own monkey impl?


therevills(Posted 2011) [#44]
what could be the bottleneck?


Wish I knew!

SetColor for images is very slow in monkey


SetColor is very slow for HTML5, it doesnt have that much affect on performance for Android.

DGuy's number's seem very close to the ones got by the other lib


I believe his numbers where taken before he changed his monkey impl - the performance is device based - I think David is testing on his NookColor, which has a better CPU/GPU than my phone.


marksibly(Posted 2011) [#45]
Hi,

> Tested with a background with alpha and a background without - same FPS in v42:

Can you try the mak/bouncyaliens test?

Click in the middle 3rd of the screen to toggle between alpha aliens and solid aliens.


DGuy(Posted 2011) [#46]
<snip>

[Edit]
See this post for updated/more valid info:
http://www.monkeycoder.co.nz/Community/post.php?topic=869&post=8371
[/Edit]


marksibly(Posted 2011) [#47]
Hi,

On android?


DGuy(Posted 2011) [#48]
Yep, on Android ... :)


marksibly(Posted 2011) [#49]
Hi,

> NOTE: I didn't really see any difference, fps-wise, between tranparent and non-transparent versions of the test.

That's weird - I get an approx 30% speed up with opaque images (Galaxy S).


marksibly(Posted 2011) [#50]
Hi,

The LG Optimus one has a weird GPU...

http://en.wikipedia.org/wiki/LG_Optimus_One

So none of the PowerVR opts are likely to help.

Is the NookColor PowerVR?

Next step would probably be to try some native c++ code, but that's a bigger project.

I'd also like to be optimizing MORE for PowerVR though, I kind of think this should be the priority.


JIM(Posted 2011) [#51]
I would say PowerVR and Adreno GPUs are just as popular in the android world. I think both deserve the same attention when optimizing (though PowerVR might be easier due to the fact that iOS devices also use them and there might be more info on optimizations)

Also, nVidia is pushing Tegra 2 (and soon Kal-El) so that might become a major player soon. Good news is nVidia's offer is quite a lot more powerful than the competition, and since monkey is hardly aimed at high-end 3D graphics, their GPUs shouldn't be a target for optimizations anytime soon.

Adreno devices: http://developer.qualcomm.com/devices
PowerVR SGX devices: http://en.wikipedia.org/wiki/List_of_PowerVR_products#Series5_.28SGX.29


therevills(Posted 2011) [#52]
Well the LG Optimus One plays Angry Birds fine and even Raging Thunder 2 is playable... I've tested quite a few Android games on it and it plays most of them well - thats why I raised this issue.

Bouncy Aliens Testing:

    | v38 | v41 | v42  
----+-----+-----+------
100 |  24 |  21 |  19
200 |  14 |  12 |  11
300 |  10 |   8 |   7
400 |   7 |   6 |   6


And little or no difference with or without alpha...


Samah(Posted 2011) [#53]
Next step would probably be to try some native c++ code, but that's a bigger project.

I tried replacing a lot of the IntBuffer stuff with the libgdx native code. There really wasn't that much of an improvement. I have a tilemap demo that runs at about 4fps on the Nexus One, but with native calls and a bunch of other small optimisations I got it to 8fps.


therevills(Posted 2011) [#54]
The biggest difference is that libgdx will use OpenGL 2.0 shaders, if available. That may cause a speed increase.


Oh BTW this is false, libgdx will only use OpenGL 2.0 if you set it in the initialize method.

Here is my Android main class for libgdx:


Notice the initialize parameters - new Game and false - the false is a flag to tell LibGdx to use OpenGL 2.0 or not:




Xaron(Posted 2011) [#55]
Ok, here some values from my HTC Desire HD:

    | v38 | v41 | v42  
----+-----+-----+------
100 |  60 |  50 |  51
200 |  55 |  30 |  31
300 |  41 |  22 |  22
400 |  32 |  17 |  17


But I noticed that v41 and v42 seems to run in higher resolution mode, at least the font is smaller which could be the reason for the lower fps.


therevills(Posted 2011) [#56]
Since v39 the Android manifest was changed to include the minimum sdk and target sdk, which makes your game use different resolutions...

Oh BTW you guys have too much money ;)


matt(Posted 2011) [#57]
dupe


matt(Posted 2011) [#58]
dupe


matt(Posted 2011) [#59]
dupe


matt(Posted 2011) [#60]
dupe


matt(Posted 2011) [#61]
dupe


matt(Posted 2011) [#62]
dupe


matt(Posted 2011) [#63]
dupe


matt(Posted 2011) [#64]
Since v39 the Android manifest was changed to include the minimum sdk and target sdk, which makes your game use different resolutions...

Good spot. This may well be contributing to the issue, the debug text is much smaller since v39 on my device so it must be running in a higher resolution? If monkey is pushing, say, twice as many pixels as libgdx then it's not really as valid a comparison.

Anyway, here are the results of the (£99 pay as you go Android phone) ZTE Blade jury.
The ZTE Blade uses a Qualcomm MSM7227 600 MHz CPU with Adreno 200 GPU.
My device is running the CyanogenMod 7 firmware, not sure if that affects performance?

libgdx: using apk from post 18

monkey: using code from post 19, assets from post 9, code built in release mode over USB direct to device.

     | Libgdx  |  v38   |  v41   |  v42
-----+--------+--------+-------+--------
 100 | 61 FPS  | 36 FPS | 30 FPS | 30 FPS
 200 | 61 FPS  | 21 FPS | 17 FPS | 17 FPS
 300 | 61 FPS  | 14 FPS | 12 FPS | 12 FPS
 400 | 54 FPS  | 11 FPS |  9 FPS |  9 FPS
 600 | 42 FPS  |  7 FPS |  6 FPS |  6 FPS
1000 | 29 FPS  |  4 FPS |  3 FPS |  3 FPS

Interesting that there's no (measurable) difference on my phone between v41 and v42?


DGuy(Posted 2011) [#65]
Some NookColor Specs:

CPU Processor: ARM Cortex A8-based Ti OMAP 3621 @ 800 MHz (same processor as Droid 2 and Droid X)

GPU Processor: PowerVR SGX530 Graphics Rendering: Open GLES1.1/2.0 (same GPU as Droid 2 and Droid X)


DGuy(Posted 2011) [#66]
Just so that we're all on the same page, I re-ran the "mak/bouncyaliens" test using the v42 version.

NOTES:
- Monkey v42
- Run on Android
- 1024x600 screen size
    | w/ Alpha | w/o Alpha
----+----------+----------
100 | 19-20    | 47
200 | 12       | 36-37
300 | 8        | 29-30
400 | 6        | 23-24

With the larger sprites (and thus more alpha-pixels), the new blending optimizations really shine.


c.k.(Posted 2011) [#67]
I might not be understanding, but what's so shiny about 6fps? o.O


DGuy(Posted 2011) [#68]
What's shiny are the numbers in the "w/o Alpha" column ... :)

Monkey used to have alpha-blending turned on all the time, thus the numbers in the "w/ Alpha" column were all there was, but now it's optimized its' usage of alpha-blending to apply it only when needed.


c.k.(Posted 2011) [#69]
Ahhhh! That's for the clarification.

Those are pretty shiny numbers. :)


therevills(Posted 2011) [#70]
Wow, thats a great performance increase on your Nook! But the only images I can really see this optimization helping is background images...

@David, could you test the code in #19 using the resources in #9 and post your results - then change the background image so it doesnt have alpha please? When I did this I saw minimum improvements (<1FPS).


marksibly(Posted 2011) [#71]
Hi,

The 'new style' manifest added in V39 is definitely making everything run higher-res here. Stuff that used to run 320x533(?) now runs 480x800.

Is it happening on everyone's phones? You can quick test by nuking the 'min-sdk/max-sdk' stuff in the manifest.

If so, this would probably account for the 10-ish% slowdown from v38-v39, which would mean it wasn't the new style vertex buffer allocation.


therevills(Posted 2011) [#72]
I added the new style vertex buffer stuff using DGuy's code to v38 (so before the min-sdk/target-sdk) and it wiped 10FPS off my game.

http://www.monkeycoder.co.nz/Community/posts.php?topic=768

Also my phone's native resolution is 320x480.


marksibly(Posted 2011) [#73]
Meh, was worth a shot...


DGuy(Posted 2011) [#74]
As requested by Therevills:

Using speedtest from #19 & Resources from #9:

NOTES:
- Monkey v42
- Run on android
- 1024x600 resolution

TEST:
A - Background & Ship w/ Alpha
B - Background w/o Alpha; Ship w/ Alpha
C - Background & Ship w/o Alpha
    | A     | B     | C
----+-------+-------+-------
100 | 41    | 42-43 | 48-49
200 | 32-33 | 34    | 43-44
300 | 27    | 27-28 | 32
400 | 21-22 | 22-23 | 24

I'm sure the reason there is only a 1-2 fps increase between test A & B is because the hundreds of alpha blended sprites are affecting FPS far more than the single background image.


DGuy(Posted 2011) [#75]
@Therevills:

I added the new style vertex buffer stuff using DGuy's code to v38 (so before the min-sdk/target-sdk) and it wiped 10FPS off my game.


Note, that "new style" is actually for the slower "old style" non-interleaved-arrays method that Mark stopped using, so I'm not surprised you saw a FPS drop. v42 uses interleaved arrays now.


matt(Posted 2011) [#76]
The 'new style' manifest added in V39 is definitely making everything run higher-res here. Stuff that used to run 320x533(?) now runs 480x800.

Is it happening on everyone's phones? You can quick test by nuking the 'min-sdk/max-sdk' stuff in the manifest.

v39+ is definitely now running at my phones native resolution.


therevills(Posted 2011) [#77]
New results for v43 - rendertest (post #18) with 100 objects:

    | v38 | v39c | v40 | v41 | v42 | v43
----+-----+------+-----+-----+-----+-----
FPS |  29 |   21 |  21 |  24 |  22 |  44



Doubled the FPS :) \o/ YEAH!!! WOOOWHO!!!


anawiki(Posted 2011) [#78]
@therevills: on Android or iOS?

not sure what have changed, but my game has huge FPS drop on Android Galaxy Tab (7") from nice 35-40FPS to 18-20FPS. Nothing changed beside Monkey upgrade from v42b to v43. I'm gonna cry...


therevills(Posted 2011) [#79]
On Android.


anawiki(Posted 2011) [#80]
So it's for the version with libgdx? Haven't tried that yet, but official drivers/libs noticed huge drop in frame rate.


clevijoki(Posted 2011) [#81]
The comparison benchmarks in posts 18 & 19 have some major flaws.

The update function is called multiple times on the monkey version of the performance comparison (posts 18 & 19), where on the libgdk it is called once per render. The sin and cos functions are not that cheap, and with 400 objects they are being called 1600 more times per frame. You should move the update function into the monkey render loop and update it with a delta to make it a fair comparison.

Next, the logic for wrapping their coordinates around the screen is bad on the libgdk version (when wrapping for the right/bottom of the screen they are waiting until the x > screen width + image width, which is a bug that means they use less fillrate than they should. The monkey version uses much simpler logic, which has the opposite bug, when wrapping across the right/bottom it just sets the coords to 0 which uses more fillrate than it should.


matt(Posted 2011) [#82]
I agree we need a better benchmark. Any volunteers? ;)


therevills(Posted 2011) [#83]
@anawiki - no the results shown are for the latest Monkey version, running on Android.

Yes Monkey does do multiple updates, but it is the rendering which is the problem.

Sin and Cos are not the problem, if you comment out all the drawing of the images Monkey will run at 60FPS ;) - I have tested this.


DGuy(Posted 2011) [#84]
Using the "mak/bouncyaliens" demo ...

NOTES:
- Run on Android
- 1024x600 screen size

v42 | w/ Alpha | w/o Alpha
----+----------+----------
100 | 19-20    | 47
200 | 12       | 36-37
300 | 8        | 29-30
400 | 6        | 23-24


v43 | w/ Alpha        | w/o Alpha
----+-----------------+-------------
100 | 31    (+10-11)  | 48    (+1)
200 | 20-21 (+8-9)    | 42    (+5-6)
300 | 15    (+7)      | 31-32 (+2-3)
400 | 12    (+6)      | 26    (+2-4)

NOTE: HICOLOR_TEXTURE [True|False] had no effect performance-wise


As with Therevills, I'm seeing FPS increases across the board, particularly with alpha sprites: Nicly Done, Mark!


clevijoki(Posted 2011) [#85]
@therevills I am not talking about what is slow in mojo, just how you would make a fair comparison between mojo to libgdx. Mojo should continue to be optimized until it is at least as fast as libgdx.