His example is:
"I need to know, that if I open chrome, while I'm resizing these pics, do I have an hour of battery life left?"

Showing a battery percentage that decreases is what Apple moved to, and I think it's the most logical and reliable way to report it.

But that doesn't solve his problem (which seems like a very common and logical use case.)


"That If i open Chrome"
can be a single tab or loading 40 tabs. And they way that Chrome is coded that will have drastically different effects on battery life. If 40 tabs are open with a flash animations and processes that are transmitting and receiving data often and loaded up with JavaScript then you may have much less battery then opening a single Chrome window with 1 tab and going to say the front page of Okayplayer.

"while I'm resizing these pics," again can mean something different. Is it using Preview and Core Image routine, or does it mean Photoshop running a long action on a folder of 50 gigabyte files that include re-sampling, sharpening, color space conversion/etc.

Translating that into time-left is trickier.

The method Apple *was* using would show wildly different estimates on remaining time when load shifted - plus it seems like there were some errors in the calculations.

I have used iStat Menu in the past to see time remaining - I'm not sure if that is accurate any longer.

And you can always look at the Average Energy impact in the Activity monitor to see if processes are consuming a lot of energy.

But it is tricky.