Re: rushed
Article: driver problems that "end up sending CPU usage skyrocketing and battery life plummeting."
I've seen SIMILAR problems within UWP [CR]apps in general, including some of the built-ins. I reported this problem during the insider program.
There's an internal architectural problem within UWP itself. Applications tend to "CPU spin" on conditions they are waiting for. It could be one of the 'WaitForXXXObject[Ex]' functions, it could be the use of 'Sleep' with a 0 value (for some reason quoting the function call tripped a security blockage) or even 'yield' doing it.
This problem also exists in POSIX systems when you return immediately from things like 'poll' and loop without using delays. In the POSIX world, though, your polling loop can use 'usleep()' which is in microseconds [no guarantee it'll be "that long", it's somewhat 'advisory'].
NOW - if _THIS_ is at the core of the problem, then it's a MAJOR ARCHITECTURAL SNAFU and Micro-shaft basically has NOT listened to *ME* on this. I know I'm right because it's measurable and I even posted the measurements, got hammered and discredited and ONE particular fanboi was even getting PERSONAL over it all. [This is how they react when faced with 'OBVIOUSLY WRONG'].
Hey Microshaft: SEE! I! TOLD! YOU! SO!!!
And so FINALLY someone wrote a driver with the SAME! KINDS! of assumptions as the main loops in UWP [CR]apps. Yeah, maybe it only showed up IN A VM when I was testing it, but it REALLY means they aren't TESTING AT ALL.
So yeah - 'rushed' aka "being cheap" and your QUALITY GOES DOWN.
icon because: to the REST of us (aka 'not Micro-shaft'), it's OBVIOUS.
Biting the hand that feeds IT
