I love Scrivener, but it’s contributing to my poor battery performance.
Under the new Activity Monitor in 10.9 Mavericks, it shows which applications require the “High Perf GPU”. Inexplicably, Scrivener is one of them.
I imagine this is just an oversight, right? Is there any reason why the High Perf GPU is forced always on when Scrivener is running? Even if Scrivener is hidden, the discrete graphics processor is turned on. It’s the only app I’ve got running all the time that requires this. As soon as I quit Scrivener, Activity Monitor reports that the discrete GPU is turned off and the system is running on only Integrated graphics.
Obviously, notebook users would love if Scrivener didn’t demand High Perf GPU always on, and only used it when it was needed (likely never?).
It’s not an oversight, no, it’s just that any application that links against the QuickTime frameworks (which Scrivener does in order to play media) automatically gets the graphics switched over to the higher performance GPU - it’s just something OS X does automatically for any app linking against QuickTime.
That said, someone suggested to me a way that might turn this off, a setting in the info.plist, and I just today released a beta with this implemented:
Unfortunately no change between 2.4.1 (22847) and 2.4.5 (25130). I opened 2.4.5 and created a new blank novel project. No other projects were open, and I didn’t make any edits to the blank novel.
Ah, yes, the option does indeed only work for more recent machines. I just double-checked it on my Retina MacBook Pro using Activity Monitor on Mavericks, and it seems to work fine. I loaded up 2.4.1, and “Requires High Perf…” was “No” until I clicked on a media file in the binder. After that, it switched to “Yes” and stayed that way. Then I loaded up the latest 2.5 beta (2.4.5), and that stayed as “No” even when a video was loaded. So this new option does seem to work, but unfortunately it won’t help those on older machines such as yourself, and I don’t think there’s anything I can do about that. As I understand it, Apple must have realised that it wasn’t always desirable to have an app switch over to using the better graphics card and so introduced this setting that apps could opt in to, but presumably the cards had to be setup to recognise it. What you can do, though, is just quit and restart Scrivener after you have viewed a media file in it, to reset it to use the lower performance card.
How would this work on one of the current (Haswell) MacBook Airs? I’m currently looking at one to replace my ageing MBK, primarily because of the long battery life. Would using Scriv actively shorten the battery life on and Air, or is this effect confined to the retina MacBooks because of their superior graphics?
It appears to default to On, regardless of whether you open a media file, or even a project. I wonder if it has to be that way, but I understand that it may not be worthwhile digging too deeply into.
The MacBook Air line does not come with two video cards, so this entire issue should be moot on them. It just applies to the MacBook Pro models (all of them, Retina included) which automatically switch between a high performance video card and an integrated card.
Ah, come to think of it, I think that’s how the older machines worked - they just switched to higher performance cards when an app was launched that linked to certain libraries (such as QuickTime). Newer machines only switch to using high performance if the library is actually used, and it’s this that the new option can switch off, telling the app not to switch at all but to stay low performance.
Testing on my I7 quad core MBP (early 2011) and the high performance GPU is not required. That said, other than rebuilding my Spotlight index, Scrivener is the most resource intensive app on the system particularly when compiling (depicted), calculating page counts, etc. Note that I am playing a video in full screen in iTunes (while waiting for the document to compile) and iTunes consumes only a fraction of the energy.
Well, it is to be expected that software will use your CPU to its fullest, when asked to perform a complex series of computations, such as compiling your book.
In contrast, decoding highly compressed audio video like a downloadable television show is a pretty efficient process that does not require a lot of CPU to do. It is not really possible to compare these two activities together. One is a very low overhead task that is highly optimised by several different industrial standards, to produce a steady rate of information on the output through your HDMI cable or the computer monitor. That’s a pretty low-demand task for your computer. It doesn’t take much for video to be played, even on a general purpose machine like a Mac. Much of those optimisations can be applied at the software level.
But like all things that require bulk calculation, where there are n million calculations to do in a stack to get the job done, there is no way to take shortcuts through that. It all has to be done from top to bottom. So you might as well just throttle the CPU up and burst through the entire list as fast as possible. There are all kinds of tasks that can cause a computer to work at high-speed for a while, compiling in Scrivener is only one of them.
Understand that we LOVE Scrivener. It is the only wp app that can handle our documents without corrupting, and it performs as well if not better than the other 32-bit apps on Mavericks. This OS X update seems to optimize for 64-bit at the expense of 32-bit performance. Just reporting issues. Scrivener is in good shape. I’ve got one 32-bit app (not yours) that makes heavy use of Java that’s so slow under 10.9 it’s completely unusable.
As Ioa says, Compile is a CPU-intensive job and will use a lot of resources. I don’t see how that can be seen as a problem given that it’s not something the app is doing all the time - it’s equivalent to hitting “build” in Xcode or another development platform.
Scrivener will be going 64-bit, but not in a 2.x update because moving to 64-bit involves dropping 10.4 support and, to get the best out of being 64-bit, moving to frameworks that weren’t available pre-10.6.
Returning to the GPU switching issue, I’m still seeing Scrivener switch to the high performance GPU as soon as it starts while running the latest version.
I’m running OS X 10.9 on a mid-2010 MacBook Pro so I understand, according to the Apple documentation about NSSupportsAutomaticGraphicsSwitching, that it is only supposed to work for 2011 and later Macs. However, I came across this plist attribute while looking for a solution to a similar problem with Postbox.
When I added NSSupportsAutomaticGraphicsSwitching to the plist for Postbox, it solved the problem, even on this 2010 machine.
Are there any ideas on why this might have worked on another app, even though not officially supported, and if there is anything I might try to get it to work with Scrivener.
Remember that the high performance GPU only gets invoked when QuickTime is called by the app. It may just be that Postbox hasn’t invoked QuickTime yet in your tests. At any rate, Scrivener 2.5 has exactly that in its info.plist file, and there is nothing else an application can do than that. As you note, this attribute isn’t supported on your machine, though, unfortunately, and there’s nothing an app can do to get around it as the AppKit does not provide access to any control over GPU switching.
