what does the isVisible property do under the hood that would affect device performance?

Solar2D General Questions/Discussion
#1

I’m been battling some major performance issues on actual devices. At first I thought I had too many objects in the playfield since removing a bunch of them entirely did improve performance, but on further testing I was able to retain the original number of objects and not lose any fps as long as I set some of the objects to isVisible=false.

I tested other possibilities, such as image size and fill rate, but nothing else affected performance in my game by more than 1-2 fps. Simply setting a bunch of the objects to isVisible=false improved my framerate from 45 to 60 fps on an iPhone 3gs. The fact that most of the objects were off screen didn’t matter, either.

So, what is so special about isVisible? What is going on under the hood that makes objects that have this property set to true so expensive? I would expect a simple display object that is not on screen, not physical, and not animating to consume very little system resources, but that appears to be so only if isVisible is set to false for that object.
[import]uid: 9422 topic_id: 5575 reply_id: 305575[/import]

#2

dont know but have a look at this too
http://developer.anscamobile.com/forum/2010/11/13/performance-tip-setting-isvisiblefalse-slow-reading-display-object-xy-slow
[import]uid: 6645 topic_id: 5575 reply_id: 18923[/import]

#3

Those are interesting findings, jmp909. I wonder if the fact that setting the isVisible property to false is so slow indicates the property is integral to something low level under the hood.

Kind of a bummer, too, since a solution to my issue I was contemplating was to create some kind of visibility culling routine that would set objects to isVisible=false if they are out of view. But if that routine itself is slow it would negate the desired performance improvements.

I wonder if this is some kind of openGL ES issue. Perhaps the engine is rendering objects that are entirely off screen, or at least performing a lot of work on them before deciding that they don’t need to be drawn. It could explain some of the performance issues you’ve been having with the Lime library on devices.

[import]uid: 9422 topic_id: 5575 reply_id: 18948[/import]

#4

As far as I am aware, an object that is off screen is actually still getting drawn, so naturally setting something to hidden via isVisible will mean that object will then not be drawn thus saving your FPS. This is the main thing I am battling with Lime and currently looking into optimisation methods to alleviate this until something else can be done at a lower level. [import]uid: 5833 topic_id: 5575 reply_id: 18952[/import]

#5

Graham, then it sounds like we have the same desire; A fast, low-level, automatic way to prevent off-screen objects from being drawn. isVisible doesn’t fit the bill since it’s not automatic, nor fast. [import]uid: 9422 topic_id: 5575 reply_id: 18964[/import]

#6

If Object.isVisible = false is to Slow for you,use Object.alpha = 0. it has the Same effect, the Object will Not Be drawn. [import]uid: 5712 topic_id: 5575 reply_id: 18965[/import]

#7

Thanks for that advice, Mike. You’re right, it does have the same effect, including the desired performance improvements. Now I just need to figure out a way to run through a couple hundred display objects spread across several parallax scrolling layers, test each for visibility in the window, and change the alpha as needed. 60 times a second.

jmp909, Maybe you can try your performance test but change the alpha as opposed to using isVisible and see if its any quicker. [import]uid: 9422 topic_id: 5575 reply_id: 18996[/import]

#8

Turns out it was actually pretty easy to make a simple routine that turns objects that aren’t within the view screen invisible (using object.contentBounds of each object checked against the screen resolution). Unfortunately the routine killed device performance more than it saved making the objects invisible.

I tried both setting objects isVisible as well as the alpha adjustment Mike described above to see if one was slower than the other, but I didn’t notice a difference on the iPhone 3 gs. On the iPhone 4 setting the alpha might have been ever so slightly quicker than isVisible.

So, back to square one. I’ve either got to reduce the number of objects or find a much quicker way to make off screen objects invisible. [import]uid: 9422 topic_id: 5575 reply_id: 19010[/import]

#9

Couple of hundreds of objects IS A LOT! We are talking about mobile phones and LUA as the language. As it stands. Corona needs to remove objects out of bounds automatically from the render que. [import]uid: 5712 topic_id: 5575 reply_id: 19012[/import]

#10

And I have even more objects than that :slight_smile:

I will report back when I have anything to show :slight_smile: [import]uid: 5833 topic_id: 5575 reply_id: 19017[/import]

#11

XenonBL:

you shouldn’t actually be checking all of the objects. you should only really check the ones in the vicinity.

i’ve discussed this here:

http://developer.anscamobile.com/forum/2010/11/22/scrolling-large-non-tiled-world-objects

my hope is that Ansca will implement these culling tests at a lower level, making it simpler for us, and giving better performance

[import]uid: 6645 topic_id: 5575 reply_id: 19083[/import]

#12

Yeah, a couple hundred display objects does seem like a lot, but most of them are off screen at any one time. As it stands now, though, I can have over 150 objects in my scene and still maintain about 55-60 fps on an iPhone 3gs without any visibility culling, even with everything else going on in my game.

But once I go much past that number of objects the framerate starts to drop, even if all those objects are off screen. Hard coding those objects to be invisible via isVisible or setting their alpha to 0 cranks the framerate back up to near 60, but dynamically checking to see if they are off screen at runtime drops the rate right back down!

So it seems like there could be a nice performance boost on devices if Corona was a little smarter about not rendering objects that aren’t anywhere near the viewport.

Edit: @jmp909 - my fear is that any kind of visibility culling check I could implement in LUA will be slower than doing nothing! For scenes with many hundreds or thousands of objects something like what you describe could offer major performance increase, I would guess, but in my case I’m only dealing with “only” 300 objects at the most. [import]uid: 9422 topic_id: 5575 reply_id: 19091[/import]

#13

I figured out a simple solution to the culling problem taking too long: I only perform the culling routine once every 10 frames. Doing that requires the visibility boundary window be a little larger than the screen resolution, otherwise objects will flicker on and off along the edges of the screen. I padded 100 pixels on each side, but that’s because none of my objects move more than 100 pixels in 10 frames and aren’t more than 100 pixels big.

So now objects that are off screen are rendered as alpha = 0, I can retain all 300 or so objects in scene at once, and I am still able to average about 57-60 fps on iPhone 3gs. iPhone 4 running the same code is getting nearly solid 60 fps. Every 10 frames the system probably slows down for an extra frame to run the culling routine, but at 60 fps it’s not noticeable.

Something like this might work for some of you who are looking for a way to cull visibility on objects to improve device performance. Simply:

Once every 10 (or 5, or 3, or whatever) enterframe events iterate through all your display objects, testing them using object.contentbounds against the boundaries of the display window. If an object is inside the boundary set its alpha to 1. If it’s outside the window, set its alpha to 0. You’ll need to adjust the size of the visibility window depending on the size and speed of your objects. Bigger and/or faster objects will need a bigger “cushion” than smaller and/or slower objects.

[import]uid: 9422 topic_id: 5575 reply_id: 19124[/import]

#14

this is quite interesting reading if you’ve not seen it yet
http://www.strille.net/tutorials/part1_scrolling.php
[import]uid: 6645 topic_id: 5575 reply_id: 19157[/import]