
Thread beginning with comment 538999
To view parent comment, click here.
RE[2]: Maybe not this time.
by Alfman on Thu 18th Oct 2012 17:05 UTC in reply to "RE: Maybe not this time."
Member since:


"the break with win32 on RT might prove to be a very good move in the long run. Devices where battery preservation is critical, are not served with lazily ported Windows applications."

Do you have evidence that battery preservation is a problem with win32s in the first place? It's a serious question since I've never seen anyone back this assertion with real data. At their core, win32 apps are event oriented, meaning that they generally only consume CPU when they're interacted with. Unless a developer has used a bad practice of polling, it's not at all clear to me how switching the API will help save the battery.

I might believe the possibility that bad practices are rampant on win32s, however even there I'd have to question this argument's validity since the win32 software I use rarely consumes CPUs in the background unless it's a daemon designed to do so.

If you're talking about foreground apps, there's nothing really preventing a metro app from wasting CPU.

If you're talking about background apps, there's no reason the OS could not have a policy to completely suspend or significantly reduce CPU to win32 apps in the background. Well behaved win32 GUI apps would not be affected during background suspension. I'd even expect the majority of "poorly" behaving win32 apps (like a ray tracer) to wake up and resume in the foreground without a hiccup.

My point is, I don't think there's any overwhelmingly strong technical reason a power policy for metro apps could not be applied towards win32 ones. And I've never seen any evidence to show that the new APIs are somehow more efficient. I don't want to assert that they are not, but I definitely need to see solid data before accepting that they are.

Reply Parent Score: 2