How would the vanilla scheduler know which process is associated with the currently active window? You're assuming there's more cooperation between the various layers of a linux desktop than I think there really are.
The scheduler doesn't need to know which process is associated with the currently active windows.
Simple heuristics can get you which to "reasonably" guesstimate which process are interactive and which aren't. For example, every X and descendant, or everything waiting on keyboard/controller or any other input.
I think the linux kernel historically did not want to prioritize interactive processes like windows and macos does.
The other thing is of course to reduce the CPU quanta, trading latency for throughput. I think most modern distribution do ship with better quanta for smooth GUI/desktop behavior.
One would think that at least a rewrite-from-scratch effort like Wayland would have come up with a solution.
Unfortunately the same problem also exists on other systems. Visual Studio even had to add a feature "Run build at low process priority" for the system to remain usable during builds:
I mean the end-user can always write the glue required to get the current running window get its process and mark that as the "high priority", but that's still working under the constraints of the regular scheduler.
Simple heuristics can get you which to "reasonably" guesstimate which process are interactive and which aren't. For example, every X and descendant, or everything waiting on keyboard/controller or any other input.
I think the linux kernel historically did not want to prioritize interactive processes like windows and macos does.
The other thing is of course to reduce the CPU quanta, trading latency for throughput. I think most modern distribution do ship with better quanta for smooth GUI/desktop behavior.