[userbinator]

The problem of smooth scrolling without much-increased CPU usage was solved long ago, in the era of 8-bit systems, by rendering slightly more lines to the framebuffer and simply changing the address in VRAM where the CRT controller started reading the data for a frame. The CPU could then render the additional scrolled-out lines in the background.

But it seems the common way to implement scrolling today is to either have the CPU or GPU actually move the data unnecessarily; there's no easy way to do the equivalent of adjusting the pointer to the window's data in memory so that the windowing system can scroll without having to perform any data movement.

Asus' trackpad driver may be at fault for turning the CPU up to 100%, but to me this is a sign of a deeper problem having to do with how inefficiently applications are doing their scrolling, and the APIs that encourage this inefficient way of doing it.

[brigade]

Well apps want to scroll more than just a static image. And it's only partly the API's fault - OS X switched to overdraw only recently in 10.9, and without any major change to API.