I tracked this down to sound system, and when I add pygame.mixer.quit() after init, script utilizes CPU as expected. I figured out that pygame creates a new process, which eats up all the CPU and the backtrace of this thread looks as follows (this is how I pointed problem to sound mixer):

This comment has been minimized.

I can reproduce this if I install from a wheel from PyPI, but not if I install pygame from source. That points to some error with the packaging - maybe an issue with the old ALSA library that it's built with. Possibly we need to try building a newer version of ALSA from source.

This comment has been minimized.

I have exactly the same problem running Pygame 1.9.3 with Python 3.5.2 under Ubuntu 1.6.04 LTS. All I have to do is pygame.init() and the CPU utilization shoots up drastically. I tried following this with pygame.mixer.quit() but it made no difference. I believe I installed Python using PIP3.

Just wondering if you have made any progress on the issue and/or have any ideas on what I should do?

This comment has been minimized.

I am actually only using pygame.display.init(). I read many guides on the high CPU utilization before I posted on the issue here, and I have no loop and am just sitting at pygame.event.wait() with no allowed events and have near 100% CPU. No other updating. Is it possible I'm not experiencing the same issue?

I'll have to try a test pygame.display.init() only and see if I get the same thing.

This comment has been minimized.

I had been through all of that above - definitely thought it was me for two weeks before I arrived here at this bug and read through everything I could find. I actually eliminated any loop entirely to be sure it wasn't that.
However, I will better confirm I am experiencing this issue before I post anything further here.

Adding the pygame.mixer.quit() also doesn't help (I didn't init it anyhow). I also tried removing pygame and compiling from source via the following but still experience the same issue. The instructions below specified that sound had been removed.

This comment has been minimized.

I think there are a couple of different bugs in play here; the original one reported appeared to be only an issue with the pre-built wheels, and went away when I built pygame from source on the target system. The new one doesn't. Unfortunately I don't have any recommendations for either right now.

This comment has been minimized.

edited

Hi I have the same issue on Arch-Linux and I can fix it with not initializing the mixer module.
Some Version info that could be important:
Python 3.6.3
pygame==1.9.3 (from pip! It works with the arch packaged pygame 1.9.3)
sdl 1.2.15-9
portmidi 217-5
sdl_image 1.2.12-4
sdl_ttf 2.0.11-4
sdl_mixer 1.2.12-5

CPU usage jumps to 90% after mixer.init() and decreases right after mixer.quit()
Off-topic... any Idea why I don't have /usr/local/lib/python2.7/dist-packages in sys.path by default and so I have to append it explicitly before I can use pygame?

This comment has been minimized.

This is a fluidinfo/pulseaudio/SDL_mixer issue, and best addressed there.

We have the option of not including fluidsynth, but then music wouldn't work for some people.
App side, a work around of using alsa SDL audio driver with an environment variable, or not initialising the music mixer if not using it.

This comment has been minimized.

edited

Can confirm same results, and using pygame.display.init() instead of pygame.init() or pygame.mixer.quit() after pygame.init() seems to have solved the high CPU problem for me. Also, I followed all the steps exactly from the manual compile page, but still get an error on install, is there a problem with that?

EDIT: BUT -- and I don't know if this is feasible with other people's applications, but -- the second I switched from using pygame.event.get() to pygame.event.wait(), usage dropped from 100% to 6%. I assume most people have more events than I do, but it has also been the only thing that worked.

This comment has been minimized.

edited

Yeah, it's a sdl_mixer issue for sure. I think it's to do with the SDL and SDL_mixer that are linked in the wheel. As you and other people state: the issue does not appear with Arch linux compiled SDL and pygame, or when you compile pygame from source and link against the Arch linux supplied dependencies.

I feel we might be able to apply all the patches that arch linux does (and more), and this would fix the issue.
See the issue here which is about applying the patches: #497

If you feel like making the wheels yourself, please see in the pygame repo, the instructions and scripts to automate building it all are there: buildconfig/manylinux-build/

If none of the patches fix the issue, then it may be to do with config, or even some sort of ABI incompatibility of the ancient linux that the manylinux wheels are made on.