Thanks for your input, Steve 
Apologies for confusing the issue. I didn’t mean to infer there was a delay in clicking these controls, just a complete lack of responsiveness whilst it renders the new state of those particular buttons. For example, when I click ‘Mute’, it mutes as expected, however, when I move off it, Audacity’s interface stops updating for ~500ms until this button changes it’s appearance.
Maybe not animations, not that I saw any frames, but they seem to be decorated with a subtle effect on my desktop. I will add a picture - It certainly doesn’t seem like a simple background colour change. It seems like a scaled, anti-aliased, light-grey circle in the light theme.
There appears to be shading/graded colour around the inside edges of the button.
I noticed that CPU usage peaks at 25% (1/4 of my quad-core) when continually mousing-over these controls, instead of the usual 2-3%, when idling or mousing over other controls. Also, on closer inspection, there seems to be an effect applied when hovering over the button, though there is this same minor effect on the other buttons they don’t hog my CPU. If it was my window manager, I would expect all buttons of that style to behave the same.
As mentioned, the slowdown affects Audacity’s entire interface, so whilst these buttons are being ‘drawn’, Audacity doesn’t update at all.
Neither changing the theme nor blending the system theme changes anything, though I do like the dark theme.
Out of curiosity, in the source code, do you know if those buttons are in any way rendered, designed or instantiated differently to the other buttons in the main window’s interface? I would think that they have to be dynamically created for each audio track whereas the transport controls don’t. Are they handled in an array or evaluated in a way which makes them heavier than their brethren? 
I also have an issue with the interface update rate - I am getting about 2 FPS from this Flatpack version when scrolling and playing back. Basically, any interaction in the tracks area is severely sluggish.
I think the previous version was v2.3.3 (I have since uninstalled and changed to v2.4.2 as advised, but I didn’t record the previous version number.)
Also, there seems to be redraw(?) issue with the horizontal scrollbar after zooming and playing it seems to come disconnected from the sample position and snaps to it’s real position on mouseover. Not sure if this can be caused by my window manager, but not sure how to rule that out. However, I am sure I would have had issues in other programs if Audacity is doing nothing out of the ordinary with it’s window’s controls
Would you have any ideas on how to check what are causing these issues? I don’t know how to trace interface performance issues in Linux. Is there anything which can analyse callback/function times, etc for the program? Again, I haven’t done any serious coding on Linux, so not sure of the state of play in that regard.
I could just go and change some settings until it [possibly] works, but I know that Linux can become troublesome if one unwittingly changes incompatible settings. I may change my window manager, but all that would tell me is that I can’t use Audacity with Compiz. Since I have a productive desktop set-up, I don’t want to sacrifice my window manager.
There must be something particular to those controls which makes them an issue. But I maybe the proverbial dog with a bone lol
Hope the above helps explain things in a bit more detail.
Thanks again.