visibleAreaChildrenList - Performance boost suggestion

[ghost]

Hi,

Inside DisplayObjectContainer render loop you iterate over all the children and check if they got visible area(hasVisibleArea), and only render them if you get a positive answer.

You can get performance boost if you will manage visibleAreaChildrenList. This way you will reduce your rander cycle.

I did something like this once. It's not a big boost but it's helping.

Note that to implement this you need a mapping between child and his index in the parent(I just stored this data in the child itself), so when the child become visible you need to place him in proper position in the visible list queue according to his actual index in the parent.

Right now I am developing a tool that use GridList and I need to add layers to it. In my specific case I will have hundreds of invisible children.

I think that every app has good potential for 10%-20% of invisible displayObjects.

[PrimaryFeather]

Thanks for the suggestion! You're right, optimizing this visibility check as you described it would for sure bring a performance gain. I will look into that the next time I work on performance!

In the meantime, in your list situation, I'd not only make those children invisible but better remove them move the display list completely. That way, they don't have to be iterated over, neither (not only in rendering, but also in the touch processing).

[IonSwitz]

I did a test here, with 200000 invisible children, and yes, the hasVisibleArea takes up some time.

However, the book-keeping of moving visible and invisible children to other lists, while maintaining what index they "really" have in in the render list order will, most likely, end up eating more CPU. I have yet to see an efficient system that manages this kind of separate lists that isn't pretty slow in itself.

A mapping in the child itself gets very tricky to manage when people start doing "addChildAt", etc. Then all children after that index must have their index bumped, and it becomes very slow to insert children in a large list.

I believe it is hard to achieve good speed increases here. The one way I can achieve this is to have a public var (not a function) to check instead of the hasVisibleArea function. That public var would have to be updated as soon as visibility, alpha or scaleX and scaleY reaches false or 0.

Ofcourse, a public var invites everyone and their brother to tamper with it, so it's a bad idea, but if you really want to boost performance here, that's how to do it, in my view, as the function call overhead is fairly large. (but I wouldn't suggest it from a design point of view)

And, of course, if someone ingenious can find a good way to juggle two separate lists, without causing massive overhead when maintaining render order, that would be super cool. I sure would want to read that solution :)

[PrimaryFeather]

Mhm, you're right, @IonSwitz — the devil is definitely in the details here. And that "public var" thing is something I'd reeeally like to avoid. ;-)

[PrimaryFeather]

In Starling 2, that's a little faster than before, because Starling stores an internal private var _hasVisibleArea:Boolean rectangle instead. That makes all such calculations faster.