The player does "Button hit testing" in response to mouse actions. It scans the Display List, looking for old-style Button Objects (the kind that you create in Flash Professional). It will do this even if there are no Button Objects in your SWF. If there is excessive time spent in this activity, it's usually because there is a large number of display list objects (e.g. thousands), and the only solution is to reduce that number. Note: this is different from the time reported for "Handling Event mouseDown" and "Event mouseDown", which cover finding and executing AS3 handlers for mouse events.
Thanks for sharing this. For info, we will also imvestigate what we could do in the future to minimize this cost. We have some ideas on what could be done to improve this. We will share more on this soon.
Sr. Product Manager | Adobe Scout
This could be the likely be cause of our issue, but one thing I wonder about is the workflow between Illustrator and Flash. We do indeed have a lot of items in the display list but a large number of them are the way Flash imports assets from Illustrator. Our artist is using Illustrator to create the graphics and then imports them into Flash. This generates quite a large hierchy of objects. Do all types of objects in the hierachy effect the performance of this or only MovieClips? Is there a way to collapse the hierachy during or after importing?
That being said the second part of our performance problems come from "Rendering Edges". Could this again be caused by a lot of items in the display list? a good 60-70% of our frame time is spent Rendering Edges and Button Hit Testing.
Are you using the optimize path tool in Flash Pro to simplify curves? This is a common issue when importing vectors from Illustrator, vector shapes are less optimized (with much more control points on the curves) causing the rendering to be more expensive than it should. Let us know!
Sr. Product Manager | Adobe Scout
Hi, I have the same issue. It will also sweep through a DisplayList branch even if mouseChildren is set to false, correct? I have lots of gamelist entries that have other children, maybe I should render the static parts into a bitmap.
I have the same problem and it's driving me nuts that I can't have so many addchilded displayobjects. Please tell me this will be fixed in the next flash player.
I can't understand what the difficulty is in telling it NOT to check button hit testing for displayobjects with mousechildren = mouseenabled = false.
Seems pretty simple to me!
Same problem here.
Having a lot of Objects (already optimized) and panning around with touch events is not usable.
Scout hints exactly to this "Button hit testing" as the main problem.
Is really no solution available ???
Have the same problem with our game www.playgodsrule.com on ipad. we mostly use bitmaps and try to simplify the display list as much as possible although we probably can do a little bet better. On ipad 2 and 3 button hot testing prevents the game to maintain 60fps while panning. Expecially since this scan seems useless when not using buttons it would be nice to disable this test all together.
I have the same problem!! When it will be fixed...soo annoying..
I have done some prelimary testing using Touch events instead of mouse and the button hit test seems to disappear. However I have not tried yet to put it on all the components on stage. I will have to do some more changing since I am using mouseX on several components that does not work with this method.
Will report back if this actually works
Multitouch.mapTouchToMouse = false;
Multitouch.inputMode = MultitouchInputMode.TOUCH_POINT;
Button hit testing seems to completely take over when display list is about 500-700 objects on ipad 2 and 3. probably sooner on ipad 1 but much later on ipad 4
Update: This actually works. It seems that using touch events instead of mouse_events completely escapes button hit testing and performs order of magnitude better. This means some refactoring for areas you want this, expecially if you are doing cross platform development.
Of course this method only works on touch devices. But this should definetly be fixed, possibly by having some global variable / function to disable it, if this is needed for combatability.