High energy usage on Mac

[geoffbeier]

I haven't yet really looked into why this is so, but it's very pronounced.

I've been playing with Decker in odd spare moments on my Mac, which means I'm often using it on battery power. If I switch away from Decker because I need to answer a few emails, I have noticed that my battery drains much more quickly than normal while Decker is running, even if it's just in the background doing practically nothing.

Activity Monitor shows Decker as having very high energy usage.

I have also noticed that my mac won't automatically sleep when Decker is running.

I'm using the build downloaded from:

https://internet-janitor.itch.io/decker/devlog/838108/decker-152

on an M1 Pro running MacOS Sonoma Version 14.7 (23H124).

I may be able to chase this down at some point. Right now, I'm just interested in trying to use Decker to make a thing for Dec(k) Month, and my brain won't let me do that until I capture this somewhere. This issue tracker seemed like the right place.

[geoffbeier]

Self-replying to note:

CPU usage is high. Decker, in the background with an empty deck open is reported by Activity Monitor as using 47.5% of my CPU (much more than anything else currently running on my system, including Chrome, PyCharm, Safari and Affinity Designer), and it's an Intel build.

I should make an ARM build and see if that helps, but if I do that right now, I'll wind up fiddling with this instead of participating in the jam :-)

[cmounce]

This also affects Linux: I've also noticed that an empty deck will use about half a CPU on my x86 Linux laptop.

According to some perf record runs on an -O2 optimized build, running in the background with a blank deck open:

• The majority of the samples (~62%) are while running void finish_flip(void){SDL_RenderPresent(ren);}
• The runner-up (~27%) is draw_frame(), which converts Decker's internal frame format (8 bits per pixel, indicating color/pattern/animation/etc) into SDL's format (32-bit RGBA).

Since SDL is taking up the largest share, I tried changing the SDL renderer mode to SDL_RENDERER_ACCELERATED. I also fiddled with the logic in draw_frame(), trying to speed it up (specifically, instead of calculating x+y*size.x and x+y*stride as array indexes, maintain pointers *src and *dest which get incremented).

• Baseline: 43.9% CPU usage
• SDL hardware rendering: 19.2% CPU
• Alternate implementation of draw_frame(): 42.4% CPU
• Both hardware rendering and an alternate draw_frame(): 16.8% CPU

So switching from SDL_RENDERER_SOFTWARE to SDL_RENDERER_ACCELERATED seems worthwhile to do. Unless for some reason we need the software renderer, but the default setting should probably be accelerated.