64-bit Mac gfx_sdl: run-away memory leak

[rversteegen]

In the last few days, kylekrack has reported twice experiencing Custom allocating tens of GB of memory and causing the computer to thrash. Once it was just sitting on the main menu. c_debug.txt shows Custom had been running about 40 min and lots of spawning of HSpeak and Game, but nothing that looks relevant.

wip 20200514.11820 gfx_sdl/music_sdl 64-bit SDL 1.2.14, SDL_Mixer 1.2.11 Mac OS 10.14.4.

[rversteegen]

kylekrack: Alright, I'm sitting and watching Custom's memory usage gradually go up while sitting on the main menu. I haven't done anything other than open an rpg file.
kylekrack: But it's steadily climbing, a few mb every couple seconds
SwordPlay: have you tried seeing what happens when you enter different editors?
kylekrack: No discernible difference

kylekrack sent me a process sampling report, which samples wha tthe process is doing every ms. Looks like the CPU usage is over 50% just drawing the screen. Mac OS seems to be spending a lot of time copying pixels and converting color formats and all kinds of stuff. I suspect this is a Mac-specific SDL 1.2 bug, since I can't reproduce it under Linux and it doesn't depend on the editor.

[rversteegen]

It seems that it's probably leaking memory every time Custom is run. Around 10GB an hour.

On a closer examination of the sampling report I noticed that it was actually using /Library/Frameworks/SDL.framework and /Library/Frameworks/SDL_mixer.framework instead of the copies embedded in the .app, explaining the obsolete versions SDL 1.2.14 and SDL_mixer 1.2.11. The @rpath change I made to try to fix #1113 had the side effect of fixing this, now it uses our frameworks. However the current mac nightlies are broken, so have to get kylekrack to test again tomorrow.

Looks like the CPU usage is over 50% just drawing the screen. Mac OS seems to be spending a lot of time copying pixels and converting color formats and all kinds of stuff.

The majority of CPU time is spent converting from the window color space to the screen color space. Using OpenGL (and I assume Metal too) bypasses this color space conversion, so I assume that gfx_sdl2 would use much less CPU than gfx_sdl on Mac.

[rversteegen]

Getting off-topic from the original problem...

The majority of CPU time is spent converting from the window color space to the screen color space. Using OpenGL (and I assume Metal too) bypasses this color space conversion, so I assume that gfx_sdl2 would use much less CPU than gfx_sdl on Mac.

Ravancloak recently complained that the OHR runs slowly on her old Mac. We all shrugged and blamed it on the Mac, but she just commented that switching to gfx_sdl2 fixes the slowness.

[rversteegen]

kylekrack found that this didn't happen when using gfx_sdl2 (not sure what arch, probably 64-bit). Marking as a gfx_sdl bug.

[rversteegen]

Closing resolved: obsolete, as we're ditching Mac 64-bit gfx_sdl builds.