A somewhat similar effect is alive and well on Android: background processes run measurably faster while user holds/moves their finger across the screen, and couple of seconds thereafter.
Mechanism is a bit different though: SufraceFlinger process that is responsible for acquiring touchscreen input, temporarily boosts CPU and GPU frequencies to make sure screen animations are nice and fluid.
A previous employer of mine explicitly requested this behaviour in their app. The app showed a map, and could align map north with compass north; to save battery, it would drop to an incredibly low frame rate (1fps?) about one second after your finger left the screen. It achieves the power goal, and has a high rating in the App Store, so I learned something about user requirements and being humble from this experience.
Question (I don't know how Android works) -- how is there even a "frame rate" for a map that isn't moving? Shouldn't it not be doing anything at all when nobody is touching anything?
Most maps these days are rendered via OpenGL (or Metal) and in those cases you still manually flip buffers and order GPU to render a frame. It's possible to control this process to avoid exessive power usage.
Of course, for most developers that might mean to not update/invalidate() a map view constantly :)
> A somewhat similar effect is alive and well on Android: background processes run measurably faster while user holds/moves their finger across the screen
Only if they do not have enough load, that is. If you have an actually loaded background process on Android it by itself will keep the clocks high. If you have a process that has short bursts of work, though, then the duration of that burst will definitely vary in response to touch boost. This is all the same as "regular" linux as it's just an aspect of most governors (ondemand, interactive, etc...)
As in, touching the display will never make this loop go faster:
void busyLoop() {
Random rand = new Random();
int data[] = new int[1000];
for (int i = 0; i < data.length; i++) {
data[i] = rand.nextInt();
}
while (true) {
measure(() -> {
for (int i = 0; i < data.length; i++) {
data[i] = (data[i] * 4) % 1000;
}
});
}
}
The hypothetical measure will observe duration to normalize to a number and then it'll stay roughly there until thermal throttling kicks in.
If, however, the loop was to look more like this:
void busyLoop() {
Random rand = new Random();
int data[] = new int[1000];
for (int i = 0; i < data.length; i++) {
data[i] = rand.nextInt();
}
while (true) {
measure(() -> {
for (int i = 0; i < data.length; i++) {
data[i] = (data[i] * 4) % 1000;
}
});
try {
Thread.sleep(5);
} catch (InterruptedException ex) {}
}
}
Then you would see the measured duration decrease when your finger was on the screen vs. not, because the kernel will consistently see that the task is not keeping the CPU it's scheduled on loaded above a threshold, so the clocks will go down all the way to idle.
Mechanism is a bit different though: SufraceFlinger process that is responsible for acquiring touchscreen input, temporarily boosts CPU and GPU frequencies to make sure screen animations are nice and fluid.