Frame freezing in windows caused in part by high poll-rate mice

Sorry for the slight vagaries in this post. I’ve recently encountered a strange problem in one of my openfl projects.

tldr: If your C++ openfl project is dropping frames in windows or flickering weirdly, and you have a high poll rate mouse (like a Razer), try reducing the poll rate to 125.

longer story: After making some code modifications I noticed my openfl app would stop updating to the screen whenever the mouse moved. As soon as the mouse stopped it would resume. What was odd was the app was still updating in the background. In fact the framerate wasn’t dropped at all. It simply wasn’t swapping the contents to the screen. If I reduced the stage.frameRate to 30 I got odder symptoms: When the mouse was moving I’d get a “ghosted” frame flickering over the top of the screen (it was always a frame from when the mouse first started moving). It appears to be some kind of buffer swapping issue (I suspect triple buffering was in effect at the lower framerates, and an extra buffer swap was causing an old backbuffer to be repeatedly flashed on screen, where as it was only double buffered at higher rates, so the extra swap was always keeping the same old backbuffer on screen).

I commented out sections of my code until I found the part responsible. However the area of code that seemed to be triggering it had nothing strange on it. It was simply a large loop performing some calculations and changing some Sprite positions. But as long as this section wasn’t commented out (and my mouse was moving) the screen would appear frozen (or flicker @ lower fps).

My mouse (razer deathadder) has a higher polling rate than normal, so I tried turning it down from 1000Hz to the normal 125Hz (fancy drivers) and sure-enough the problem stopped.

If I were to guess I’d say a combination of GC heavy code and a high number of mouse events (so again - GC heavy?) is causing some kind of timing problem at the end of frames, causing an extra buffer swap.

It’s a really odd problem. Sadly it’s a large project, and I don’t have a simple test scenario to share, but if you’re getting framedrop or flickering problems and you have a high poll rate mouse in windows, try reducing it as a quick solution.

To those working on openfl or lime: There’s something odd going on here… Check your buffer swaps and GC collect timings. Sorry I can’t offer any code to test against at this time. But if this resembles a known problem then here are some more clues.

Can you tell if this occurs with -Dlegacy, or without it, or both? That would be very helpful to know what code path it’s going down


This is just in legacy and hybrid (my fps sits at around 200 throughout).

v3 isn’t usable as it seems to have a memory leak. Framerate starts at 25 and rapidly drops in to single figures. (unrelated to my mouse movements)

Are you using Intel GPU and vsync? V3 has a problem with vsync on Intel GPUs.

I noticed memory leaks in BunnyMark example but not in other examples. Clean up at exit seems to be forgotten in some places, but I didn’t observe growing memory usage during runtime.

Nope; Nvidia. Bunnymark runs fine for me in v3. Seems to be something specific to this project.