The forums have permanently moved to
forum.kirupa.com. This forum will be kept around in read-only mode for
archival purposes. To learn how to continue using your existing account on the new forums,
check out
this thread.

Mouse Movement causing Flash Player slowdown

I am struggling with an issue at the moment related to mouse events or more specifically mouse movement. I have found that moving the mouse in my game causes it to slow down. Rapidly moving the mouse can actually freeze the game, I believe EnterFrame events are actually dropped when the mouse is moving rapidly.

I thought at first that it must be something I coded incorrectly so I used the Flex 4 Beta's performance tools and analyzed the Flash 10 SWF that I build using Flash CS4. Mouse Events were the leading performance hog by far.

Whenever the mouse moved the CPU usage would skyrocket. I then tried an empty Flash App with no Actionscript, I had the same CPU spike.

So if I'm getting this problem with a Blank SWF how come I don't see this problem talked about all over the internet, how is every other Flash Developer not running into this problem?

Same problem

I apologize for resurrecting an old thread, but I have this same problem, and stumbled upon this topic during a search. Rather than making a new one, I decided to append my information onto this thread.

It seems that moving the mouse frantically can slow down or shut down the SWF. I am using CS3 and AS3, exporting for Flash Player 9, using the auto-generated html page, for testing purposes.

There is a single mousemove event listener in my game, attached to the stage. There are no problems when the SWF is viewed by the standalone player. The problem seems to manifest on fast machines only when using firefox, while on slow machines it becomes a problem with both firefox and IE (haven't tried other browsers.)

I would appreciate it if anyone can offer some insight into this issue.

Fixed

Nevermind me... Fixed my own problem.

For anyone else having the same issue, it's adobe's fault like usual. To fix this issue, I wrote my own simple html page instead of using the auto-generated one, and I disabled transparent windowless mode. So the culprit is either their js script, or the transparent windowless mode (or both!).

I think I recall having this issue when i had a Mouse Move Listener. My solution was actually to remove the listener. I realized that I can poll the position of the mouse whenever I need it, rather than constantly fireing an event whenever the mouse moved.

Its interesting to note, that if your framerate is 30 FPS for example, then the ENTERFRAME listener fires 30 times per second. However if the mouse is moving, the MOUSEMOVE listener fires much much more often than 30 times per second. This sort of surprised me when I found it out.

Every time the mouse moves, the OS sends events to the player (which in the case of browser-based SWFs I believe even go through the browser then from the browser to the player). The player then intercepts those events and performs additional calculations to handle changes that may be necessary for them, such as button state changes and any mouse events supported by the player that need to be dispatched etc.

One thing you can do is, if you have nothing interactive in your animation, is to play it in an off-list display list, capture it in a BitmapData every frame, just just have a single Bitmap instance of that capture on the screen showing the animation. That should help with performance. Even if the mouse moves within that bitmap, the reduced display list should help limit the impact (and this can be a good approach in general for performance)

senocular, what about setting mouseEnabled and mouseChildren = false? That BitmapData workaround is interesting but is it necessary?

That should probably help. The logic behind what Flash uses to determine how much work it has to do with a new mouse event is complicated and "magical". Limiting what it can consider interactive or necessary for possible updates would likely help.

Interesting suggestions. Well it's a game (interactive) and runs at 60 frames per second. I guess it does make sense that a fast mouse movement can trigger more than 60 times a second, since a mouse can move over more than 60 pixels and if you go with an enterframe listener instead, there is always a chance you'll miss some of the mc hittests the mouse did run through if they are small. Also, the enterframe listener always runs 60 times a second, while the mouse listener can potentially run 0 times a second. But I guess a static 60 is more reliable than a variable 0-1200.

I think this problem is beyond code optimization though, it is something to do with the browser side of things. Perhaps the firefox flashplayer is not optimized when it comes to passing on the mouse coordinates in transparent windowless mode.

Oh, and regarding bitmaps - when working with symbols, I make sure that anything that doesn't need to be a movieclip is not a movieclip, but a graphic instead. I believe since graphics are noninteractive, they require less processing power, get ignored in hittests, and occupy less memory. Am I correct in my assumption?

I'll say again how I solved this problem, and you can decide if it applies to you.
I also have a game and I'm only targetting 30 FPS (60 is a lot to ask I think).

I call gameUpdate() and gameDraw() once per frame, ie 30 times per second. When I gameUpdate(), I need to know the current position of the mouse, in order to update the angle of the player. I *could* have used a mouseMoveListener to update the angle of the player, but this would have potentially updated the player's angle 1000 times per second (or whatever it is), causing big slowdowns. Instead, I dont have a mouseMoveListener, and I simply grab the mouse position once in my gameUpdate(), guaranting that it only happens 30 times per second (no more, no less). There was absolutely no need to update the player's angle more often than calling gameUpdate(). Ask yourself if you really need a mouseMove listener at all.

I'll say again how I solved this problem, and you can decide if it applies to you.
I also have a game and I'm only targetting 30 FPS (60 is a lot to ask I think).

I call gameUpdate() and gameDraw() once per frame, ie 30 times per second. When I gameUpdate(), I need to know the current position of the mouse, in order to update the angle of the player. I *could* have used a mouseMoveListener to update the angle of the player, but this would have potentially updated the player's angle 1000 times per second (or whatever it is), causing big slowdowns. Instead, I dont have a mouseMoveListener, and I simply grab the mouse position once in my gameUpdate(), guaranting that it only happens 30 times per second (no more, no less). There was absolutely no need to update the player's angle more often than calling gameUpdate(). Ask yourself if you really need a mouseMove listener at all.

Yep, I understand your case, and you wouldn't need a mousemove listener. So your solution works for a case like yours (and a majority of cases I'd say.) However in my case I do have to know exactly what points the mouse moves through (some kind of painting like subroutine.)

Anyway, I already solved the problem by disabling transparent windowless mode which I didn't need, so