QScrollBar painting gradually slowing down

When repeatedly scrolling in a QTableView, QTableWidget, QListWidget or a QListView, a QScrollBar drawn with a native Mac style will slow down the paint performance significantly over time. This performance "rot" is associated with an increase in RAM. When the window receives a mouse or keyboard event, after a short lag the paint performance returns to normal. The length of lag is correlated with the paint time. It doesn't seem to make any difference whether the window is active or not, as long as it is visible and repainting.

The attached minimal example is a QTableWidget that scrolls randomly to cells every 10ms. Paint performance on the QTableWidget is timed for each paint and displayed, averaged over 20 paints. 

In typical performance on my machine, the example starts with average paint times of around 2-4ms. After 4 minutes the average paint time is around 75ms. Once the window is clicked, or a key is pressed, after a short lag, the performance returns to initial speed before starting to climb again. 

On the other hand, without QScrollBars or when using the "Fusion" theme, the paint performance stays relatively constant, as expected. To see this, use the "-w" flag when running. (See lines 94 & 95 in main.cpp)

A .png showing a graph is attached.

NB: I have tested this with QTableView, QTableWidget, and QListWidget. The System Preferences/General/Show scroll bars setting seems to have no impact on the example. I have not been able to replicate this behaviour with a QPlainTextEdit, except for the lag. The lag has also been present in my own app even with scrollbars off— perhaps this requires further investigation.

*EPILEPSY WARNING* The example has very fast repeated scrolling.