The main place this comes up is in cases where the main window is doing something clever to gather the information to display itself. For example, Activity Monitor doesn’t suddenly stop using half your CPU when you hide it.
Mail.app probably keeps a big scrollable list-control for the selected view in-memory for as long as you have the window open. So it might be a bad idea to do this if you’re one of those people who never archive anything (i.e. practice “Inbox Infinity.”)
I thought that was a static thumbnail?
> For example, Activity Monitor doesn’t suddenly stop using half your CPU when you hide it.
It does for me, which is why I keep it hidden when I’m not actively using it.
Nah, it updates (...as far as I can recall.) Try opening a chat client, minimizing the chat window, and then sending a message from another device to yourself.
I believe it’s just using the same call into the compositor that Mission Control uses to display your windows and spaces. Those are all live. (They might have a lower update rate, though.)
> It does for me, which is why I keep it hidden when I’m not actively using it.
Interesting. This might be down to Activity Monitor being written to respond to a message letting it know that its view is entirely obscured, and the Activity Monitor main-window view-controller deciding in response that there’s no point in it polling the system if all it’s going to do when re-visible is discard all the stuff it learned in the mean time and re-poll again to get the newest data for the view.
I can’t recall whether Activity Monitor has any historical/time-series views built in? If it does, then if you hide Activity Monitor with those active, it should keep using CPU, to gather the data for that view, whether it’s rendering it or not.
I can’t speak to Mail, but in general a Mac app with no visible windows may actually take zero CPU, because (if it’s written to allow for it) the OS may kill the process entirely.