There's something I fundamentally don't understand about how multitasking works in Linux (and probably also in general). If I understand correctly, each time a process wants to change its output to the screen, it needs to do some computations and send the data. But if I understand correctly, processes can hog the CPU for up to 100ms before being pre-empted under the default settings of most Linux distributions. This would seem to preclude the possibility of processes being unblocked frequently enough to be able to refresh the screen at 60Hz. In light of this, I guess there's probably a whole host of fundamental misunderstandings I have about how Linux manages its scarce CPU time and/or about how processes send data to I/O devices.
Question. What's going on here?
You seem to be confusing different scheduling policies.
In Linux, there are several scheduling policies that determine different time slices. The 100ms default time slice is only for the SCHED_RR policy, which is used for real-time processes. In reality, no normal process runs under SCHED_RR.
Normal processes run under SCHED_OTHER, which is the default scheduler policy. Under this schedule, the time slice is dynamically determined at runtime, and is much lower. By default, it can be anywhere between 0.75ms to 6ms. You can see these default values (in nanoseconds) defined in kernel/sched/fair.c as sysctl_sched_min_granularity and sysctl_sched_latency respectively. You can get the real values on your system by reading /proc/sys/kernel/sched_min_granularity_ns or /proc/sys/kernel/sched_latency_ns.
You can learn more about the Linux kernel CFS scheduler here (or here for more documents).