Typically, foreground processes require “snappy response-time,” but they (by their nature) actually consume almost no CPU time.   They spend all their time waiting for I/O.

Background threads, operating at very slightly reduced priority, actually wind up consuming the lion’s share of the available CPU time.   They more or less round-robin among themselves.   But, because of their priority relative to the foreground task, they immediately yield control to the foreground task when necessary, so that those are “snappy.”

I find that it is most satisfactory when background threads do not do any direct user-interface I/O at all.   They don’t have any sort of message processing queue with the GUI.   So, from the scheduler’s point of view, their requirements are (and they remain) obvious and consistent.   It’s clear what kind of servicing they need to get, and those needs don’t change.

In my opinion, you should never elevate the priority of any foreground task.   Nor is it necessary to “unduly lower” the priority of a background task.   The OS scheduler will always attempt to keep all CPU’s and all I/O devices as continuously busy as it is possible for them to be.   The priority values, relative to all other priority values of extant processes at any moment in time, are essentially suggestions to that scheduling algorithm.