Static background image causing big FPS drop

cocos2d for iPhone » Programming » cocos2d support (graphics engine)

Static background image causing big FPS drop

(51 posts) (9 voices)

Started 1 year ago by dolor
Latest reply from araker

Tags:

12 Next »

dolor
Member

Hello everyone,

i'm using cocos2d to render a certain scene in my application, as CA was too limited. I've got most of the scene itself done, and am currently working on optimizing. It's a landscape with clouds flying through it, sometimes raining. But even without the rain, i'm at a average FPS of 45, spiking 5 FPS around that (40-50 is normal). With the rain (made using a CCParticleRain particlesystem), it drops to 20-25.

However, when i remove the background image (the sky), i'm at a constant fps of 60 without the rain, and 25-30 with the rain (however the rain moves much less sluggish so i suppose the bigger drop is because of more drops actually being calculated in comparison). After i discovered that that background image was the cause, i've been looking in ways to render this image more efficiently. It's a simple fullscreen image, 197KB on disk non-retina and 590 KB on disk retina, in PNG format.

What i've already tried is using a atlas. Currently i'm cutting up the image in 2 even pieces with a CCSpriteBatchNode and adding them to that batchnode, but that did not increase the FPS, or only very marginally. I've also tried adding them to an empty CCSprite, as suggested here: http://www.cocos2d-iphone.org/forum/topic/5196/page/2 (2nd post from the bottom). This also barely helped. I've also used the CCBackgroundSprite suggested in that thread, without any help.

I'm using Cocos2D version 0.99.5. Also, likely not unimportant, i'm using cocos2d in combination with UIKit. I'm developing the scene in a seperate 'tech demo' as I like to call it, and i've added the director to a UIView. This UIView will be added in the rest of the app later and displayed fullscreen. I'm rendering the sky, the landscape and the clouds all in seperate CCLayers. I always add the sky to the scene first, and i've tried both adding all other layers to the scene directly or to the backgroundlayer.

I believe that is all the information for now. I'll be looking further and adding details as I find them, but after 2 days of searching I have not yet found anything working so I would like your input. Thanks in advance! ;)

Posted 1 year ago #
varedis
Moderator

The age old question - Are you testing the FPS on the simulator or an actual device (if so what device)

Posted 1 year ago #
dolor
Member

Stupid of me to forget that 'detail'. I'm always testing on the device, as i'm developing on the first intel macmini which is too slow to decently run. I'm using an iPhone 4.

Posted 1 year ago #
Birkemose
Moderator

I use a 1.gen unibody MacBook pro for development, and on that, sim is about the same speed as a 3G ( 10-20% faster, and of cause no drops when mum calls )
So of cause you can judge speed in sim.

Whatever you render, it will take time, and on 3G / MBPro, you will easily drop to 30. Dont think you wont.
If you are a good programmer, drop in FPS should be pretty much linear with pixels rendered, unless you have some heavy math behind the scenes.
That means, that if your rain renders 10% of the screen, but drops FPS more than rendering an entire background, then your raincode is flawed.

PS
I only answered because it gave me the opportunity to write "raincode"

PSPS
Just saw your answer, and if you drop to 20 FPS on a iP4, you might be doing something seriously wrong. Its a killer device.

Posted 1 year ago #
varedis
Moderator

Seems rather strange, how big is your background image?

Posted 1 year ago #

dolor
Member

Maybe this is a help too, as i see most other posts including the code. I didn't believe there to be anything wrong with the part where it's adding the layers, but I thought I'd add it anyway.

This is the init method of my UIView 'AnimationController'. All the layers being added to the animation or to 'background' are subclasses of CCLayer.

self.view = [[UIView alloc]initWithFrame:frame];
EAGLView *glview = [EAGLView viewWithFrame:frame];
[self.view addSubview:glview];

director = [CCDirector sharedDirector];
[director setOpenGLView:glview];
[director setDisplayFPS:YES];
if( ! [director enableRetinaDisplay:YES] )
{
    CCLOG(@"Retina Display Not supported");
}

//Set up layers
animation = [CCScene node];

background = [[BackgroundLayer node]retain];
[animation addChild:background];
clouds = [[CloudLayer node]retain];
[celestial addChild:clouds];
landscape= [[landscapeLayer node]retain];
[background addChild:landscape];

//Start playing
[director runWithScene:animation];

Posted 1 year ago #

dolor
Member

@Birkemose: That's what I had been assuming, so i ran through all the other code before trying to remove that background image. Nothing boosted it nearly as much (about 3-5fps max) as removing that image, though most 'tick' methods looked quite heavy to me. I even used a Stopwatch class i found somewhere to find out how long that particular part of the code took, and apparently i heavily underestimated the calculating and looping power of the iPhone and CPUs in general.

@varedis: fullscreen, no scaling. So the non-retina version is 320*480, the retina version is 640*960. I've not been able to test it on a non-retina device apart from a first generation iPod touch, both since i don't have my testers (15 via Testflight) living near me apart from the guy with the iPod touch, and since most of the images are still only in retina (UIKit didn't find scaling much of a problem, but cocos2d does want all the images in both -hd and normal). I also get no memory warnings, apart from a short low-level one at initialization sometimes.

Addition: Though i doubt it's related, i now tried cutting the background in 4 pieces as another post suggested. It didn't improve anything, but the spikes appear to be nearly gone; it's almost the whole time at exactly 42.9 FPS.

Posted 1 year ago #
Birkemose
Moderator

Always good to include some code, but this certainly isn't where things go wrong.

Also @varedis, render speed isn't affected by image size, only memory consumption. So while large images might cause hickups, it shouldn't cause persistent low FPS.

You need to profile your app.

Posted 1 year ago #
Birkemose
Moderator

Personally, I think one of the MAJOR things that lacks in cocos2D, is a number for overdraw.

People will happily draw the screen 3 times without knowing ( not saying that this is the case here ), but if you got feedback on this, a lot of "why is my app slow?" would be solved easily.

Posted 1 year ago #
dolor
Member

I've tried profiling before for CPU time, but i couldn't make up from it what was wrong. I'll profile it now and post the results here, collaborative thinking always works better... especially together with people who know more about it than you ;) Though last time i profiled it i was looking for a particular part of the code which i thought took long. Turned out that was only about 0.0005 seconds.

Whoops, i also found out the app is currently using 50 MB. That sounds like too much...

Edit: Ok, i'm afraid i'll be needing some hints. To be honest with you, i have no idea what to look for. 13.1% of the cpu time goes to mach_msg_trap, which sounds like something i don't have control over. 6.5% to objc_msSend, of which most goes to the CCTimer update: method, which looks like it's for drawing (2.2%). However, this does not sounds significant enough to cause this low an fps, is it? Sorry, instruments have always been my worst part at this entire iPhone developing stuff, though i've spent about 2 workweeks trying to learn them... (Ah, lookie there, i just found something especially designed for FPS it seems :))

I've also found this thread, which sounds like the same problem i'm having: http://www.cocos2d-iphone.org/forum/topic/912 Lots of people there with the problem but no solution found...

Posted 1 year ago #
dolor
Member

Here are the results from the OpengGL ES analysis: http://imageshack.us/photo/my-images/232/screenshot20110525at160.png/ I'll be searching for those entries now, but i wanted to share it with you guys in the meanwhile.

Posted 1 year ago #
Birkemose
Moderator

Rereading the thread, you must f... up somewhere else.

Rendering a full screen image on an iP4, is like ZAP, and it is over.

Posted 1 year ago #
dolor
Member
Yep, that's what i assumed. But whatever i'm trying, that background image keeps getting the app to lag, no matter how i add it to the scene...

Edit: To likely add some more confusion: the non-retina version causes the same FPS drop on my iPhone 4. Commenting out the one line that adds it as a child removes the lag altogether. Here's the code adding the image to that layer just to be sure (i noticed i only posted adding the layers to the scene):
```
sky = [CCSprite spriteWithFile:@"Sky.png"];
sky.position = ccp(160, 240);
[self addChild:sky];
```
This is in the init of BackgroundLayer. These three lines seem to cause a 20-25 drop in fps...
Posted 1 year ago #
Birkemose
Moderator

I think it was Benihana who once wrote: The problem is always in the code they dont quote.

Much truth in that I think.

Anyways, the code you quoted, is good code .. apart from the much to generic name, the hardcoding of png and position, and the retainment by using container. Not to bad for 3 lines of code.
Just kidding ;)

Posted 1 year ago #
dolor
Member

The name is slightly simplified for this thread ;) and i'm almost sure it's in the code not quoted, which is why it wasn't included initially. Problem is: i have no idea what code :S currently testing with various other images as a background, hopefully allowing me to find what exactly is causing this. :)

Edit: Apparently my code had kept the old, retina-sized images. If i do use a nonretina one (as the size is not hardcoded it keeps it centered, 160*240 on a retina screen), it goes to a stable 60 fps. if i do hardcode the size (actually i set the scale to 2), it drops to 55 on average.

Posted 1 year ago #
abitofcode
Moderator

Have you got any space on your spritesheet to include the background image, or tiles used to recreate the image. At least you'll save some draw calls (and texture rebinding).

Posted 1 year ago #
Birkemose
Moderator

That sounds pretty weird, and your code looks okay.
Having said that, part of being a "good programmer", is also being able to figure out why things go wrong, and I am sure you will.

My own take on this, when I really get stuck, is doing something completely different. Forget about it. Code another part. And as the brain works in mysterious ways, you suddenly think: "Maybe it is because I ..."

Either that, or you will have to settle being a taxi driver ;)

Posted 1 year ago #
dolor
Member

I don't use a spritesheet yet apart for the 3 different clouds. I can try including it in that spritesheet, but do you think it will matter that much? I'll be including it in the meantime.

Posted 1 year ago #
dolor
Member

@birkemose Yep, and it's what i love about programming the most, finding solutions to problems that seem too big to solve at first glance :) in almost all cases i indeed get those 'of course!' moments, but in those cases it usually has to do with calculations or at least parts of coding i am familiar with. Unfortunately, i still don't know much yet about these things. So i'll first be gathering more information and then go back to optimizing my particlesystems or something like that ;)

Posted 1 year ago #
rpowell
Member

Interesting problem you have.

TBH this slow down I would have expected. When you have multiple sprites conflicting to draw in the same area & moving does this not slow down FPS to work out what to draw? I see this on my project.

Secondly if you were to rerun the project & run with each sprite type seperately (clouds,bg & rain) Whats the bet the addition of the cpu usage for each does not equal the total for what your seeing.

The point I'm trying to make is the problem may be with how it determines what to draw in the frame buffer

Just my 2 cents :)

Posted 1 year ago #
dolor
Member

So the main problem is overlapping sprites? I might actually be able to remove that for a large part... about half the screen is the landscape overlapping the air. I will try that and come back to you guys. I always thought the iPhone could determine that very efficiently, but that was about UIKit. I suppose openGL does not have that same capability out of the box? @birkemose, was this the problem you meant with overdraw?

Edit: I've tried adjusting the part it 'clips' from the sky, using CCSpriteBatchNode, to only show the part above the landscape. Still at 42-50 FPS though. Even stranger: If i only draw a small part (160*80 pixels large) that's up in the sky, it's stuck at 49-51 fps. If i leave that small part out i'm back to 60. Somehow i'm getting the feeling i'm doing something wrong with the batchnode...

Posted 1 year ago #
Birkemose
Moderator

Yes. Overdraw is the magic word when it comes to rendering stuff fast.

The ideal thing would be 1, ie any pixel on the screen is only drawn once.
The term stems mostly from John Carmacs work ( that is why he drives a Ferrari, and I still walk ). He implemented, backwards culling, spatial hashes, and a lot of other shit I can not even start to understand, but the basic idea is to not draw anything that will be drawn upon later. Thus overdraw.

In 2D ( and with modern hardware ) it of cause is not as important as it was back in the assembler days, but you can still easily kill the performance of the GPU if you don't pay attention.

BTW, try to draw a 100% transparent image. Will be quite a bit faster than drawing an 100% opaque image. Because no drawing.

Posted 1 year ago #
dolor
Member

Also read the post before yours, i edited a bit.

But i believe i don't comprehend your last post. 100% transparent = invisible and 100% opaque is visible, right? Then why would i draw it 100% transparent? Or do you mean test it with the image being transparent, so you know if it's the drawing code or something else?

Posted 1 year ago #
Birkemose
Moderator

My point was, that rendering nothing is the fastest approach. OGL knows that, and 100% transparent pixels takes no ( or little ) time to render.
That should be your approach when adding sprites.

Overdraw is still the magic word though.

Posted 1 year ago #
dolor
Member

Yea, i supposed that not rendering anything would be faster ;) but what's the use of a sprite if it's invisible? What exactly do you mean with that being the approach when adding? Only if you add new sprites, or always set sprites to be invisible before adding it as a child?

Posted 1 year ago #
araker
Moderator

@dolor, an iPhone4 shouldn't have any problems with this, have you tried a release build? Another thing, what happens when you add the OpenGL directly to the window (and don't do anything with a UIView)?

As far as I know it's faster to render a opaque object than a transparent one. For blending the color values of the layers beneath need to be queried when a pixel isn't fully opaque. So a opaque pixel needs less calculations then a transparent one. This doesn't change anything about overdraw being bad for performance.

Another thing, if you're going to display a UIView on top of cocos, it's better to try out a different director. The displaylink director (the default) doesn't play nicely with UIKit and CA.

Waar kom je trouwens vandaan?

Posted 12 months ago #
Birkemose
Moderator

I would not mess with you araker, but I am pretty sure that rendering fully transparent pixels is pretty much faster than rendering opaque / semi transparent ones.

Posted 12 months ago #
dolor
Member

I believe that araker is assuming you meant semi-transparent pixels. My personal thoughts were that completely transparent is fastest, then completely opaque, and lastly semi-transparent. I'll try removing the UIView in the equation now. However, i'll most likely be needing it in the complete app anyway. I've never heard about different directors however; can you tell me more about that? (I'll be searching for it too)

Lastly, how did you know i was Dutch? ^^

Edit(Yea, i love editing instead of posting more, much edits): Ok, i found the information about the other CCDirector types:

CCTimerDirector - Uses an NSTimer
CCDisplayLinkDirector - Uses CADisplayLink
CCFastDirector - Uses NSInvocation
CCThreadedFastDirector - Uses NSThread

However, what i made up of that thread, the default director (CADisplayLinkDirector i believe?) is generally the fastest one. Apart from scrolling in a UIScrollView pausing the animation (which also happens with me but doesn't concern me too much as it's only in place for testing purposes), i couldn't find any case where you should be using another director.

Also, i'm currently testing some more without the clouds. I accidentally had set the background to scale 2 (a normal complete CCSprite, of which i had the code commented out while trying atlassprites), and i found it caused the fps to be stable at 60. Without the clouds, i currently reach an almost stable 60 fps too, slightly lower.

While that fact slightly confuses me (though it has only 1/4th of the pixels to draw, now that i think of it), i'm particularly interested in the 60 fps without the clouds. I'm positive i had tried that before without any help, but it seems they might be the cause after all. Apparently the clouds moving over the background image is too much for cocos2d to handle. As you said, Birkemose:

The problem is always in the code they dont quote.

The strange thing is, however, that with both 1 and 28 clouds, it lags just as much. really strange...
Please tell me if you're interested in the code of the clouds. I'll first be looking into what i can optimise there and modify the code a bit so it's postable.

Posted 12 months ago #
araker
Moderator

I can't find any proof that opaque pixels can be discarded in the blend function. I guess that was wishful thinking. Every pixel (opaque or transparent) needs to be put through the blending equation. That's why it's good to avoid transparent pixels when possible, since they still add-up in the computation.

I was thinking about semi-transparent instead of fully transparent indeed.

@dolar

I can see it in your eyes ;) And it doesn't hurt either that I can see your IP address plus that I've seen your previous post in the particle designer thread.

This topic contains some useful information about director types. You can change the director type in your app delegate.

Posted 12 months ago #
dolor
Member

Ah, didn't see you were a mod. That explains seeing the IP, though i can't remember what i posted in the particle designer thread which would reveal my secret identity ;) no idea what I posted however. That post you linked was exactly the one i got that comment from.

I'm currently modifying parts of my code so i can post it here. If i comment out the part that adds my clouds to that layer, 60fps. If i don't comment out but edit my constants to only show 1 cloud, it drops by 20fps. Same with 28 clouds. I'm quite sure now it's somewhere in the code i'm using for the clouds, however i still don't really get it.

Update: Now also tried using preloaded CCTextures using CCTextureCache. Doesn't improve the FPS either.

P.S. Can you use differently scaled sprites from the same batchnode? I thought that was the reason i got the warning that you shouldn't call 'draw' on a sprite created from a batchnode before, but when looking at the documentation it doesn't say anything about that. Perhaps that would prevent my lag, but i can't be sure because it won't work. Guess i'll have to make a seperate thread for that problem though, if i can't figure it out.

Until i post the code, here's a quick explanation of how i made my cloudsystem:
The goal was to show a certain number of layers of clouds with different depths to create a 3d effect. I'm creating 30 clouds in the layer's init method, add them as childs to the layer and add them all to an array. The clouds are subclasses of CCSprite created from CGImageRefs. As i got several images, i'm using a switch statement to determine the used CGImageRef.

Then, every step, i move a 'point' along a virtual line, and then divide that line in differently sized parts. Then, a cloud is taken from the array and placed at regular intervals on those lines to distribute them nicely. It's rather hard to explain like this (it took me several sheets of paper to get the whole calculation completely clear for myself), but i hope that I managed to explain that part good enough.

First i suspected this calculation to take such a long time, but this appears not to be the case. Now all that i changed was actually adding those clouds to the layer, so they're still being animated somewhere in the void i suppose, just not drawn over the background. I've also tried to not change the scale of the clouds, but showing them all fullscale just caused an even bigger fps drop (as suspected, since it has more pixels to overdraw).

Posted 12 months ago #

RSS feed for this topic

12 Next »

Reply »

You must log in to post.