Could you please try the build from here: https://dcpomatic.com/temp/2184-macos-sleep/c3ce1bf/osx-10.10/
to see if it works any better?

The observed %CPU goes to approx. 680% (instead of approx. 450%).
This is still a bit lower than with an unlocked screen (750%).

But the framerate does not appear to really suffer from it.
A more controlled benchmark would be needed to exactly determine this:
it's a bit hard to see watching the fps number in the DOM GUI with real footage that
causes constantly changing framerate performance ..

It's also possible that the percentages shown by "top" have a slightly different meaning
when the screen is locked vs. normal.

But this change is definitely a big improvement!

Thanks for checking it. I guess a really good test would be to transcode the same DCP twice, once with the server kept awake (by moving the mouse or whatever) and once without, and to see how long it took in each case.

@carl merged this change to v2.16.x as c3ce1bf707fb5308f4b96cb96ed6e8d29335a319

Already working on it .. :-)

Amazing, thanks!

I tested with 10 minutes of blu-ray content (14400 frames)
and with the "Only servers encode" setting enabled.

The results:

2.16.1 + screen unlocked: 8.92 fps
2.16.1 + screen locked: 2.50 fps
2184-macos-sleep + screen unlocked: 8.93 fps
2184-macos-sleep + screen locked: 8.73 fps

So the fix almost completely restores the screen-locked performance!
And there is no difference when the screen is unlocked.

PS: the fps in the log file is only presented as an integer (for example "2" instead of "2.50").
Maybe it's better to add some decimals to the number!

Great! Thanks for checking it out.

Which log file are you talking about with the integer FPS?

I get a file called "log" in the project directory.
The last line after a job is something like this:

   "Thu 17 Feb 2022 08:41:49 PM CET: Transcode job completed successfully: 2 fps"

Maybe the content depends on the settings?

These are my Log settings

log_settings.png (12,460 bytes)   

log_settings.png (12,460 bytes)   

Got it, thanks!

I've added a fix for the decimal places in the log locally.