We're experiencing this on a desktop application (the Raven) and it also seems to be related to frequent calls being made to repaint for our meters. This only became an issue after the El Capitan update. In our case, we have a separate thread running at 60fps which looks for any changes made to our incoming metering values and calls repaint() on the meter whenever necessary. After the El Capitan update, it seems that something is happening where the repaint calls are "piling up" and causing our main thread to become unresponsive.
For instance if you start playback (meter values start changing and calling repaint) then try to hit the stop button, you'll get a small delay (1 second) from when the button is clicked and when it actually changes. If you let playback continue for 20 seconds or so, this delay becomes much longer (6 seconds, etc.) so it seems like the frequent calls to repaint are "piling up" and preventing the main thread from doing anything else until they are cleared. Interestingly, the CPU of our program hardly even rises during this situation (totaling ~20%) so I have no idea what's causing the lag. It's almost as if the OS is preventing our app from drawing more CPU in order to account for the frequent repaints.
As a sanity check, going off of Jules' comments in similar threads suggesting simplifying the paint callback, I tried commenting out all code in our meters' paint function, so they were completely blank. This had no effect on the result and I still experienced the accumulating lag. Does anyone have a clue as to what could be going on here? What even happens when repaint is called on a blank child component that could be causing slowdown? Is there overhead associated with drawing the section of the parent component over which it exists? Isn't that cached?
Here's a gif showing what I'm talking about with paint debugging enabled. Despite the fact that the meters are completely blank, we're still seeing drastic slowdown:
