Hacker News new | ask | show | jobs
by Havoc 4253 days ago
Ignoring the trackpad angle...the idea of ramping up the CPU on scroll does make some sense. If you think about smartphones...the first place people bitch about lag is scrolling. Thats likely what the engineer was thinking about when they linked trackpad to CPU like that.
4 comments

No, I don't think it makes any sense at all. CPUs/OSs have built-in mechanisms to automatically adjust frequency depending on the actual workload. If scrolling involves a minimal workload then it should remain in low-power state. This is a really power-hostile solution to solving a problem which should be solved another way. At the very least, if this really is an intractable lag problem (which I doubt - other manufacturers seem unaffected), then the driver should call an OS API that says something like "latency-sensitive user input has started/stopped", and then the OS makes the decision about whether to boost the CPU frequency, or do something more sensible, or be updated in future to use new hardware features to solve the problem even better, etc.

This particular hack is just poor engineering. And users should at least be given the choice between "drain my battery or add a bit of lag", if the manufacturer can't figure out how to remove the need to make that choice.

OSX ramps up the CPU during scrolling, but never enough to turbo the fans. And if the scroll view is GPU accelerated (now nearly all of them), it only climbs to 10% instead of 50%.
Thats mostly because Android used to have a really bad vsync/input synchronization before project butter[1] - the system had anywhere between 0 and 16.7ms to render the entire screen (which means easily < 4ms every 4 or 5 frames) instead of having consistent 16.7ms every time.

No matter how fast the components, scroll input events would often happen 1ms before rendering time and a frame would have to be skipped, causing choppiness.

[1]: https://www.youtube.com/watch?v=Q8m9sHdyXnE