4 ms·
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 co
by kees99 7y ago
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.
- ben_w 7y agoA 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.
- mehrdadn 7y agoQuestion (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?
- markdown 7y ago> could align map north with compass north Maybe the map turns as you turn so as to maintain compass north.
- sprafa 7y agoI assume you might need it for the “person” icon while the user moves around the city?
- izacus 7y agoMost 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 :)
- kllrnohj 7y ago> 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.